You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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?
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)
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.
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.
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:
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:
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:
Comment 18365
Date: 2013-01-22 09:29:08 +0100
From: @sjoerdmullender
Oct2012-SP3 has been released.
The text was updated successfully, but these errors were encountered: