RexCall Data Type

[Michael Alexeev <mi...@gmail.com>]

Hi All,

Please consider the following SQL:

select INT_COLUMN * INT_COLUMN from SOME_TABLE;

The data type of the INT_COLUMN * INT_COLUMN expression is still an INTEGER
provided that the INT_COLUMN type is INTEGER as well. This could lead to a
potential overflow if the column value is big enough.

Is there a way to force Calcite to promote the final expression type to
BIGINT in this case to make sure that its result always always fit into a
valid range? The same question applies to other binary operations with
numeric types.

Thank you,
Mike

Re: RexCall Data Type

[Julian Hyde <jh...@apache.org>]

You probably wouldn’t want Calcite to promote every int * int operation to a higher type; otherwise int_column * int_column * int_column would need a 96 bit (or larger) integer type.

The simplest thing is cast one or both or the input values to the larger type, and the result will be that type:

> select CAST(INT_COLUMN AS BIGINT) * INT_COLUMN from SOME_TABLE;

Julian


> On Oct 2, 2017, at 6:25 PM, Michael Alexeev <mi...@gmail.com> wrote:
> 
> Hi All,
> 
> Please consider the following SQL:
> 
> select INT_COLUMN * INT_COLUMN from SOME_TABLE;
> 
> The data type of the INT_COLUMN * INT_COLUMN expression is still an INTEGER
> provided that the INT_COLUMN type is INTEGER as well. This could lead to a
> potential overflow if the column value is big enough.
> 
> Is there a way to force Calcite to promote the final expression type to
> BIGINT in this case to make sure that its result always always fit into a
> valid range? The same question applies to other binary operations with
> numeric types.
> 
> Thank you,
> Mike