New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unexpected results when comparing integer with string containing value out of range of that integer datatype #7997
Comments
I suppose what is wrong is this:
|
|
Expected results are:
|
INTEGER
As a side effect I've fixed overflow detection in CVT_decompose(). Therefore wait for QA before back-porting fix. |
It seems to me that some problems still exist.
For SMALLINT it seems strange that following raises num ovf:
(in both snapshots) Similar for BIGINT:
And this seems regression (?):
(expected: one record with value = -166027665). And for INT128 we can see the same strange result for:
|
…h string containing value out of range of that integer datatype
On 2/10/24 16:06, Pavel Zotov wrote:
Therefore wait for QA before back-porting fix.
It seems to me that some problems still exist.
Pavel, I suppose now I've fixed all related bugs. Please recheck with
next snapshot.
|
I still can't understand whether following script issues correct (expected) output or no:
Output:
IMO, comparison for negative values must follow same rules as for positive ones. Checked on 6.0.0.264. |
On 2/15/24 11:54, Pavel Zotov wrote:
|-- ########################################## check-1
#################################################### select t.x as
sml_r6 from t_sml t where t.x <= (
(-170141183460469231731687303715884105728) || 1 ); select t.x as
int_r6 from t_int t where t.x <= (
(-170141183460469231731687303715884105728) || 1 ); select t.x as
bigint_r6 from t_bigint t where t.x <= (
(-170141183460469231731687303715884105728) || 1 ); select t.x as
int128_r6 from t_int128 t where t.x <= (
(-170141183460469231731687303715884105728) || 1 ); --
########################################## check-2
#################################################### select t.x as
sml_r6 from t_sml t where t.x = 1 and t.x >= (
(999999999999999999999999999999999999999) || 9 ); select t.x as int_r6
from t_int t where t.x = 1 and t.x >= (
(999999999999999999999999999999999999999) || 9 ); select t.x as
bigint_r6 from t_bigint t where t.x = 1 and t.x >= (
(999999999999999999999999999999999999999) || 9 ); select t.x as
int128_r6 from t_int128 t where t.x = 1 and t.x >= (
(999999999999999999999999999999999999999) || 9 ); |
IMO, comparison for negative values must follow same rules as for
positive ones.
Yes - it should, provided you issue same (symmetric) comparisons.
Which is definitely not your case - why additional "t.x = 1"?
|
I've done copy-paste "dummy block" in previous query, sorry.
(changes start from line marked as 'check-2'). And my question actually is: why BIGINT and INT128 can not be properly compared with 't.x' when we do NOT use additional "where t.x = -1 and ..." or "t.x = 1 and ..." ? |
On 2/15/24 12:30, Pavel Zotov wrote:
And my question actually is: why BIGINT and INT128 can not be properly
compared with 't.x' when we do NOT use additional "where t.x = -1 and
..." or "t.x = 1 and ..." ?
They can't be compared because a value, causing overflow of given type,
can't be located in the index. First condition x = -1 (or +1) makes is
evauated using index, and second condition is checked in usual way for
records, selected from index. For smaller types that value fits into
index range, therefore it works.
|
It looks weird. For SMALLER types we can compare but for bigger - not. |
…ing containing value out of range of that integer datatype; fixed regression in test core_1274
…ing containing value out of range of that integer datatype; fixed overflows that happen when index key is composed
…ntaining integer value out of bigint range (cherry picked from commit 7531251)
…h string containing value out of range of that integer datatype (cherry picked from commit 1192082)
…ing containing value out of range of that integer datatype; fixed regression in test core_1274 (cherry picked from commit 69d52d3)
…ing containing value out of range of that integer datatype; fixed overflows that happen when index key is composed (cherry picked from commit 337ca49)
…ntaining integer value out of bigint range (cherry picked from commit 7531251)
…h string containing value out of range of that integer datatype (cherry picked from commit 1192082)
…ing containing value out of range of that integer datatype; fixed regression in test core_1274 (cherry picked from commit 69d52d3)
…ing containing value out of range of that integer datatype; fixed overflows that happen when index key is composed (cherry picked from commit 337ca49)
Consider the test case below. It is unexpected that, if the second query returns
true
, the third query returns an empty result, because the value of theWHERE
predicate should betrue
as well.I'm not sure if the result of the second query is expected, but if it is, the third query should return
-766027665
. If removing the PK constraint, the third query returns-766027665
, which is expected.I found this in version LI-T6.0.0.253 where I built from source code f4e725f
The text was updated successfully, but these errors were encountered: