|
[
Permalink
| « Hide
]
Ann Harrison added a comment - 02/Oct/14 03:44 PM
Dialect one doesn't support 64bit integers. The dialect has been deprecated for over 15 years. Should the developers spend time enhansing it after all that time?
Show me please, where 64int in this query.
INTEGER officially 32int This query does not work too: SELECT BIN_SHL(CAST(1 AS INTEGER), CAST(1 AS INTEGER)) FROM RDB$DATABASE Dialect 3 is not a enhancing for the legacy systems. Internal implementing BIN_SHL through int64 for dialect 1 is a bug. BIN_AND working wonderful in the Dialect 1, for example. Firebird 3 accepts BIGINT type in dialect 1.
Oleg, BIN_AND/OR do not expand the result, but BIN_SHL does (higher bit moves), so the result becomes 64-bit. I'm not sure whether it's correct for BIN_SHR though.
Dmitry, BIN_SHR has a bug too: ... Client SQL dialect 1 does not support reference to BIGINT datatype.
Why shift in the RIGHT expand the result? It is illogical. I think shift fuctions implemented __int64 BIN_SHR(__int64,__int64), but it is incorrect for Dialect 1 May be this bug reproduced only in the 64bit version? |