Skip to content
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

Overflow in calculation #3189

Closed
monetdb-team opened this issue Nov 30, 2020 · 0 comments
Closed

Overflow in calculation #3189

monetdb-team opened this issue Nov 30, 2020 · 0 comments

Comments

@monetdb-team
Copy link

@monetdb-team monetdb-team commented Nov 30, 2020

Date: 2012-11-19 18:54:58 +0100
From: @skinkie
To: SQL devs <>
Version: 11.13.3 (Oct2012)
CC: @njnes, @drstmane

Last updated: 2013-01-22 09:29:08 +0100

Comment 17951

Date: 2012-11-19 18:54:58 +0100
From: @skinkie

User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.17 (KHTML, like Gecko) Chrome/24.0.1312.14 Safari/537.17
Build Identifier:

sql>select * from (select 1 as x) as x where x in (1234567890);
MAPI = monetdb@localhost:60001
QUERY = select * from (select 1 as x) as x where x in (1234567890);
ERROR = !overflow in calculation.

Wouldn't it be possible to have something more meaningful, for example showing the actual value that raised the overflow?

Reproducible: Always

Comment 17952

Date: 2012-11-19 19:01:52 +0100
From: @drstmane

Overflow occurs when trying to cast value 1234567890 into a tinyint (1 byte).

Plan generation gone wrong due to too eager aiming for minimal implementation types?

sql>select * from (select 1 as x) as x where x in (1234567890);
overflow in calculation.
sql>plan select * from (select 1 as x) as x where x in (1234567890);
+-------------------------------------------------------+
| rel |
+=======================================================+
| project ( |
| | select ( |
| | | [ tinyint "1" as x.x ] |
| | ) [ x.x, in (tinyint[int "1234567890"] as L2.L1) ] |
| ) [ x.x ] |
+-------------------------------------------------------+
5 tuples (0.533ms)

Work-around:

sql>plan select * from (select cast(1 as integer) as x) as x where x in (1234567890);
+----------------------------------------------+
| rel |
+==============================================+
| project ( |
| | select ( |
| | | [ int[tinyint "1"] as x.x ] |
| | ) [ x.x, in (int "1234567890" as L2.L1) ] |
| ) [ x.x ] |
+----------------------------------------------+
5 tuples (0.433ms)
sql>select * from (select cast(1 as integer) as x) as x where x in (1234567890);
+---+
| x |
+===+
+---+
0 tuples (3.083ms)

Comment 17953

Date: 2012-11-19 19:24:27 +0100
From: @skinkie

It accidently triggered in a very long range of pasted values in the IN (...) part of the query, so this is just the minimal case I wanted to reproduce. In that specific case, the IN was operating on an integer.

But my point here is more in sense:

ERROR = !SELECT: identifier 'blabla' unknown

I would expect something like:

ERROR = !SELECT: calculation on '1234567890' overflowed.

Comment 18011

Date: 2012-11-26 16:04:03 +0100
From: @sjoerdmullender

Changeset 04369d14a3b0 made by Sjoerd Mullender sjoerd@acm.org in the MonetDB repo, refers to this bug.

For complete details, see http//devmonetdborg/hg/MonetDB?cmd=changeset;node=04369d14a3b0

Changeset description:

Moved the generation of overflow messages down.
This way the message can (and now does) contain the values that caused
the problem.
This fixes part of the problem in bug #3189.

Comment 18022

Date: 2012-11-27 10:52:43 +0100
From: @sjoerdmullender

Changeset 0f366c399f79 made by Sjoerd Mullender sjoerd@acm.org in the MonetDB repo, refers to this bug.

For complete details, see http//devmonetdborg/hg/MonetDB?cmd=changeset;node=0f366c399f79

Changeset description:

Added test for bug #3189.

Comment 18168

Date: 2012-11-28 09:29:55 +0100
From: @njnes

Changeset df6fb82513f6 made by Niels Nes niels@cwi.nl in the MonetDB repo, refers to this bug.

For complete details, see http//devmonetdborg/hg/MonetDB?cmd=changeset;node=df6fb82513f6

Changeset description:

fixes for bug #3189, ie use correct types on both sides of the IN.

Comment 18365

Date: 2013-01-22 09:29:08 +0100
From: @sjoerdmullender

Oct2012-SP3 has been released.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
1 participant