On 2-2-2018 17:25, Alex Peshkoff via Firebird-devel wrote:
On 02/02/18 10:57, Dmitry Yemanov wrote:
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.

I propose that the scale is communicated when requesting info on columns or parameters using isc_info_sql_scale, but it should be removed from the request blr as it is part of the Decimal128 value.

The fact that for p <= 18 decimal/numeric the sql_scale information is used for the necessary rescaling is just an implementation detail. When we communicate the scale inline in the Decimal128, it is still pertinent metadata that needs to be communicated in some way (eg I need to know, because that is a requirement of the JDBC specification). Not putting it in sql_scale wouldn't make a lot of sense to me, because it is by definition the expected/defined scale of the column or parameter, so it is the right place to put that in.

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.

It will need to be changed if we want to be able discern numeric and decimal (in the current form) or decfloat, numeric and decimal (in the proposed form).

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.

It is exactly the reverse, Firebird DECIMAL is compliant with the spec, NUMERIC isn't:

26) NUMERIC specifies the data type exact numeric, with the decimal precision and scale specified by the <precision> and <scale>.

27) DECIMAL specifies the data type exact numeric, with the decimal scale specified by the <scale> and the implementation-defined decimal precision equal to or greater than the value of the specified <precision>.

We could consider 'deprecating' NUMERIC, and only apply the extended precision to DECIMAL, but that might be more confusing.

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