[
https://issues.apache.org/jira/browse/FLINK-24847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17441146#comment-17441146
]
Marios Trivyzas commented on FLINK-24847:
-----------------------------------------
I'd vote to not allow overflow by default, have a flag so that user can switch
on to avoid the checks and allow overflow (also improve performance by skipping
the checks).
When overflow happens though, it would be nice to have consistent behaviour
(always rely on Java's cast, and not use BigDecimal.intValue() or similar). In
my opinion this is of low priority to fix, since overflow is already producing
non-standard results, but we should document this properly, and it will be
user's "responsibility" to treat/understand what happens.
> Decide the overflows behaviour
> ------------------------------
>
> Key: FLINK-24847
> URL: https://issues.apache.org/jira/browse/FLINK-24847
> Project: Flink
> Issue Type: Sub-task
> Components: Table SQL / API, Table SQL / Planner, Table SQL / Runtime
> Affects Versions: 1.14.0
> Reporter: Francesco Guardiani
> Priority: Major
>
> Right now we have inconsistent behavior when it comes down to overflows,
> depending on whether the value comes from a literal or from a value generated
> by the runtime (eg after a sum).
> In particular, I tracked down an issue when trying to execute
> {{CAST(9.2345682E9):INTEGER}} which returns {{644633299}} instead of
> {{2147483647}} (the result of {{(int)9234567891.12f}}, because Calcite
> changes the type of the literal to INTEGER, skipping completely our casting
> logic in codegen and just forcing us to generate a literal using
> {{literal.getValue().intValue()}} (Note that Calcite uses {{BigDecimal}} for
> every numeric, no matter the type).
> Relevant code related to the issue:
> * {{RexBuilder#makeCast}}
> * {{GenerateUtils#generateLiteral}}
> This issue brings me to the following questions:
> * Should we throw an error on overflows?
> ** If yes, should this be the default behavior or just something we configure
> behind a flag?
> ** If no, should we have consistent and useful results when overflows (e.g.
> max value)?
> *** If yes, what should be those overflow values?
> *** If no, do we keep everything as it is and document that the user needs to
> be careful about overflows?
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
