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:
case SQL_DEC_FIXED:
bout.write(blr_dec_fixed);
bout.write(field.getScale());
break;
It works as expected, but when I change it to
case SQL_DEC_FIXED:
bout.write(blr_dec128);
break;
I get incorrect results, that is: it behaves as if I wrote
bout.write(blr_dec_fixed);
bout.write(0);
on parameters sent from client to server, but as
bout.write(blr_dec_fixed);
bout.write(field.getScale());
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
--
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
https://lists.sourceforge.net/lists/listinfo/firebird-devel
