[FLINK-24847] Decide the overflows behaviour

• Type: Sub-task
• Status: Open
• Priority: Major
• Resolution: Unresolved
• Affects Version/s: 1.14.0
• Component/s: Table SQL / API, Table SQL / Planner, Table SQL / Runtime
• Assignee: Marios Trivyzas
• Reporter: Francesco Guardiani
• Created: 09/Nov/21 11:46
• Updated: 07/Feb/22 13:46

Description

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?

Issue Links

• is duplicated by: FLINK-25434 Throw an error when BigDecimal precision overflows.
• relates to: FLINK-24420 Casting to a "narrower" type doesn't throw exception but follows Java overflow