[
https://issues.apache.org/jira/browse/FLINK-24847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17460093#comment-17460093
]
Timo Walther commented on FLINK-24847:
--------------------------------------
btw couldn't we solve this chain by a planner rewrite rule to have the same
semantics like literals in Calcite for multiple casts on a field?
> 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)
