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 

Reply via email to