Literal 65536 (interpreted as int) can not be multiplied by itself w/o cast if result more than 2^63-1

[pavel-zotov]

Following relates only to FB 4.x+ where we have new datatype: INT128.

Literal 65536 is interpreted as int, 4294967296 - as bigint:

SQL> set heading off;
SQL> set sqlda_display on;
SQL> select 65536 from rdb$database;
...
01: sqltype: 496 LONG scale: 0 subtype: 0 len: 4
...

SQL> select 4294967296 from rdb$database;
...
01: sqltype: 580 INT64 scale: 0 subtype: 0 len: 8
...

When i try to multiply BIGINT literal (4294967296) by itself then result will be greater than 2^63-1.
In this case FB silently casts result to INT128:

SQL> select 4294967296*4294967296 from rdb$database;
...
01: sqltype: 32752 INT128 scale: 0 subtype: 0 len: 16
...
                         18446744073709551616

But when i try to multiply INT literal by itself, and do this four times, then result must be the same as previous, but it can not be obtained because INT64 is used instead of INT128:

SQL> select 65536*65536*65536*65536 from rdb$database;
. . .
01: sqltype: 580 INT64 scale: 0 subtype: 0 len: 8
. . .
Statement failed, SQLSTATE = 22003
Integer overflow.  The result of an integer operation caused the most significant bit of the result to carry.

It will be useful if one can get rid of this w/o explicit cast of literals to required ("bigger") datatype.

[AlexPeshkoff]

The funny is that:

select (65536*65536)*(65536*65536) from rdb$database;

executes fine.

That's the result of already discussed issue with int * bigint. But now I start thinking that it should really be int64 (not bigint like now) in order to avoid inconsistencies.