[
https://issues.apache.org/jira/browse/FLINK-21125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17272526#comment-17272526
]
Jark Wu commented on FLINK-21125:
---------------------------------
Thanks for the detailed investigation and summary.
I think the configuration name {{table.exec.strict-mode.enabled}} is a bit
general, it's hard to know the strict mode refers to the numberic overflow
problem.
What do you think about using {{table.exec.numeric-overflow.handling}} and
provide:
- **{{unchecked}}**: The default value. Keep the behavior as is, the same to
Spark, Hive, and Java. "in case an operation causes an overflow, the result is
the same that the same operation returns in a Java/Scala program (eg. if the
sum of 2 integers is higher than the maximum value representable, the result is
a negative number)."
- **{{error}}**: throw exception and indicate users to use a larger numeric
type when overflowing.
- **{{silent}}**: use the MAX_VALUE instead and generate a warning log, but no
exception when overflowing.
I think we may still need the original behavior which is the same to Spark,
Hive, and Java. Therefore, I proposed the above 3 enum values.
What do you think? [~shared_ptr][~twalthr]
> 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(amount) 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 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)
