[
https://issues.apache.org/jira/browse/FLINK-21125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebastian Liu updated FLINK-21125:
----------------------------------
Description:
Overflow is not calculated correctly in the build-in sum function of Blink
planner.
For a aggregate calculation such as:
{code:java}
CREATE TABLE TestTable (
amount INT
);
insert into TestTable (2147483647);
insert into TestTable (1);
SELECT sum(id) FROM TestTable;
The result will be: -2147483648, which is an overflowed value and no exception
was thrown. {code}
The overflow occurs quietly and is difficult to detect.
Compare the processing semantics of other systems：
* *mysql*: provide two SQL mode for handling overflow. If strict SQL mode is
enabled, MySQL rejects the out-of-range value with an error, and the insert
fails, in accordance with the SQL standard. If no restrictive modes are
enabled, MySQL clips the value to the appropriate endpoint of the column data
type range and stores the resulting value instead. FYI:
https://dev.mysql.com/doc/refman/8.0/en/out-of-range-and-overflow.html
* *presto*: all numeric types are automatically auto Cast to Long type, and If
the long is out of range, an exception is thrown to prompt user.
IMO, exception hint is necessary, instead of quietly overflow.
was:
Overflow is not calculated correctly in the build-in sum function of Blink
planner.
For a aggregate calculation such as:
{code:java}
CREATE TABLE TestTable (
amount INT
);
insert into TestTable (2147483647);
insert into TestTable (1);
SELECT sum(id) FROM TestTable;
The result will be: -2147483648, which is an overflowed value and no exception
was thrown. {code}
The overflow occurs quietly and is difficult to detect.
Compare the processing semantics of other systems：
* *mysql*: provide two SQL mode for handling overflow. If strict SQL mode is
enabled, MySQL rejects the out-of-range value with an error, and the insert
fails, in accordance with the SQL standard. If no restrictive modes are
enabled, MySQL clips the value to the appropriate endpoint of the column data
type range and stores the resulting value instead.
* *presto*: all numeric types are automatically auto Cast to Long type, and If
the long is out of range, an exception is thrown to prompt user.
IMO, exception hint is necessary, instead of quietly overflow.
> Sum or Sum0 overflow quietly
> ----------------------------
>
> Key: FLINK-21125
> URL: https://issues.apache.org/jira/browse/FLINK-21125
> Project: Flink
> Issue Type: Bug
> Components: Table SQL / Planner
> Reporter: Sebastian Liu
> Priority: Major
>
> Overflow is not calculated correctly in the build-in sum function of Blink
> planner.
> For a aggregate calculation such as:
> {code:java}
> CREATE TABLE TestTable (
> amount INT
> );
> insert into TestTable (2147483647);
> insert into TestTable (1);
> SELECT sum(id) FROM TestTable;
> The result will be: -2147483648, which is an overflowed value and no
> exception was thrown. {code}
> The overflow occurs quietly and is difficult to detect.
> Compare the processing semantics of other systems：
> * *mysql*: provide two SQL mode for handling overflow. If strict SQL mode is
> enabled, MySQL rejects the out-of-range value with an error, and the insert
> fails, in accordance with the SQL standard. If no restrictive modes are
> enabled, MySQL clips the value to the appropriate endpoint of the column data
> type range and stores the resulting value instead. FYI:
> https://dev.mysql.com/doc/refman/8.0/en/out-of-range-and-overflow.html
> * *presto*: all numeric types are automatically auto Cast to Long type, and
> If the long is out of range, an exception is thrown to prompt user.
> IMO, exception hint is necessary, instead of quietly overflow.
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
