Hello all,
What is the semantics of arithmetic overflow in SQL?
I assumed that SQL is supposed to use checked arithmetic, but it seems like
this behavior is configurable for some database systems. Having checked
arithmetic seems to be the in the spirit of SQL to provide exact results. You
don't want to use wrap-around arithmetic when you manage your bank account.
For example, if you look at an operator like Multiply in RexImplTable.java:
defineBinary(MULTIPLY, Multiply, NullPolicy.STRICT, "multiply");
dispatches to:
/**
* A multiplication operation, such as (a * b), without
* overflow checking, for numeric operands.
*/
Multiply(" * ", false, 3, false),
This suggests that Calcite adopts unchecked arithmetic. And indeed, today
Calcite ignores arithmetic overflows when evaluating expressions. Moreover,
since it uses Java as a runtime, and Java has no arithmetic on Short or Byte,
all computations are done using integer or long. Which means that lots of
potential overflows are completely ignored. I have fixed this problem recently
for Decimals, but the problem persists for all integer types.
Ideally whether arithmetic is checked or not should be a property of the type
system.
However, this will make the implementation quite complex, since there are lots
of places where Calcite generates arithmetic expressions.
I think this is a long-standing bug in Calcite, which I'd like to fix. But what
is the right solution?
I have filed a related issue: https://issues.apache.org/jira/browse/CALCITE-6379
Mihai
