On 02/02/18 10:57, Dmitry Yemanov wrote:
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.
I.e. to represent NUMERIC/DECIMAL(M, N) where M > 18 will be used
SQL_DEC34 with sqlsubtype 1/2? But what should be the value of
sql_scale? On the one hand in should be non-zero to let user know how
many digits after decimal point may be used. On the other - for non-zero
scale in numeric fields we always used to follow the rule: value =
basic-type-value * pow(10, -scale) but most of people here tend to
require SQL_DEC34 to be already scaled correctly.
Let's make final choice before making any changes.
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)? sqlsubtype 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.
sqlsubtype is always zero now but certainly this can be changed.
BTW - the difference between NUMERIC vs DECIMAL in firebird is lost.
According to standard DECIMAL(s,p) must be exactly as precise as
declared, while NUMERIC(s,p) must be at least as precise as declared. In
firebird both behave as NUMERIC.
------------------------------------------------------------------------------
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
