01.02.2018 20:24, Mark Rotteveel wrote:
Point taken, but my suggestion was more that we now don't utilize
the Decimal128 to its fullest for decimal, and users of the direct
API now need to handle decfloat and decimal(19+, x) in a very
different manner even though the underlying datatype is the same
(and provides the convenient feature to communicate the scale inline).
Damned, I still do not catch where is the problem. I reviewed ISQL
code - we have DecFixed interface that provides conversion to/from
strings and BCD. And it's implementation is less that once screen of
a code.
It is exactly one screen more than necessary. SQL_DEC16 and
SQL_DEC34 covers whole possible set of values. SQL_DEC_FIXED is just
unnecessary and there is no point to have it at API level at all.
I tend to agree that there's no sense to use yet another data type at
the API side. SQL_DEC16/DEC34 can be easily used instead.
That could work, but that will require identification (eg through
subtype), that this should be handled as a fixed scale column or
parameter, which could mean SQL_DEC34 subtype 0 is DECFLOAT (as is now),
SQL_DEC34 subtype 1 could be NUMERIC and SQL_DEC34 subtype 2 could be
DECIMAL.
Isn't it the case already (for SQL_DEC_FIXED)? sqlscale was always used
to indicate INTEGER vs NUMERIC vs DECIMAL, I suppose it's preserved for
SQL_DEC_FIXED and can be used for SQL_DEC16/DEC34 too.
Dmitry
------------------------------------------------------------------------------
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
