[#CORE-4569] BIN_SHL and BIN_SHR does not work in Dialect 1

Firebird Core

BIN_SHL and BIN_SHR does not work in Dialect 1

Created: 02/Oct/14 09:23 AM Updated: 23/Sep/15 11:29 AM

Component/s:

Engine

Affects Version/s:

2.5.2, 2.5.2 Update 1

Fix Version/s:

3.0 Beta 1

Environment:

64bit version for Windows

QA Status:

Done successfully

Description

« Hide

DIALECT 1

SELECT BIN_SHL(1, 1) FROM RDB$DATABASE was return

An error was found in the application program input parameters for the SQL statement.
Dynamic SQL Error.
SQL error code = -804.
Data type unknown.
Client SQL dialect 1 does not support reference to BIGINT datatype.

All

Comments

Change History

Subversion Commits

Sort Order:

[ 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?

[ Permalink | « Hide ]

Oleg Matveyev added a comment - 02/Oct/14 04:28 PM

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.

[ Permalink | « Hide ]

Adriano dos Santos Fernandes added a comment - 02/Oct/14 04:32 PM

Firebird 3 accepts BIGINT type in dialect 1.

[ Permalink | « Hide ]

Dmitry Yemanov added a comment - 02/Oct/14 04:45 PM

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.

[ Permalink | « Hide ]

Oleg Matveyev added a comment - 02/Oct/14 05:25 PM

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?