I some changes were made in https://github.com/FirebirdSQL/firebird/commit/1636227d401f3c7e9678dc8cd317af5fae9a56bc

I'm observing something odd. It is my understanding it would be possible to drop use of blr_dec_fixed, and use blr_dec128 instead.

If I define the BLR message descriptor using:


It works as expected, but when I change it to


I get incorrect results, that is: it behaves as if I wrote


on parameters sent from client to server, but as


on fetch for values from server to client.

Inserting a value like 12345678901234567.891 into a DECIMAL(19,3) then results in the value 12345678901234567891.000 being inserted (and returned to the client on select).

So it looks like there is something missing when receiving parameter values from the client.

Also, it would be helpful if CORE-5728 (Field subtype of DEC_FIXED columns not returned by isc_info_sql_sub_type) gets done soon.

On 3-2-2018 14:05, Mark Rotteveel wrote:
To summarize the proposed change:

The SQL_DEC_FIXED type is dropped in favour of using SQL_DEC34 with subtypes, and I assume this to also mean the blr_dec_fixed is removed, including the need to send the scale separately in the request BLR.

As a result, SQL_DEC34 will represent:

DECFLOAT with subtype = 0
NUMERIC(p > 18) with subtype = 1
DECIMAL(p > 18) with subtype = 2

For subtypes 1 and 2, isc_info_sql_scale (and XSQLVAR.sqlscale and equivalent in new API) will report the defined scale of the column or parameter. For subtype 0 (decfloat), it will always report scale as 0.

Open issues

1. When sending values from client to server, will Firebird reject values with the wrong scale for subtypes 1 and 2, or round them to the correct scale?

As an example, will sending 12.345 (12345e-3) for a DECIMAL(34,2) be rejected with an incorrect scale error, or will it be rounded appropriately (to 12.34 (1234e-2) assuming half even rounding)? Similar sending 123 (123e0) will that throw an error, or 'round' to 123.00 (12300e-2)?

If the second option, errors would only be raised if this would produce an overflow (eg sending 123e34 can never be made to fit a decimal(34,2))

If we follow the SQL rules for store and retrieval assignment (9.1 and 9.2), then we should allow values with a different scale, and round appropriately.

But would this lead to differences in behavior compared to DECIMAL and NUMERIC with precision <= 18? I'm not sure if it is currently possible to send 12345 with sqlscale = -3 and have it converted correctly to a scale 2, or not. I can experiment with Jaybird to check, but if someone knows that would save me some time (as Jaybird itself already rounds before sending, and circumventing that is a bit of a pain).

Am I missing anything else?


Mark Rotteveel

Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Firebird-Devel mailing list, web interface at 

Reply via email to