Francesco Guardiani created FLINK-24847:
-------------------------------------------
Summary: 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
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)
