Commented by: @aafemt

I would rather consider it as a bug "Firebird does not support high precision decimal literals".

Commented by: @mrotteveel

That is an incorrect qualification: Firebird does support them, but you need at least 20 digits otherwise it is a numeric(18,x), which BTW has it is own problems as a literal with 18 or 19 digits is rounded but that is done for backwards compatibility. And the scientific notation is - by the SQL standard - reserved for approximate numeric literals, and Firebird has a non-standard(?) extension that reuses that format for DECFLOAT if the exponent is greater than 308 (absolute).

My request is for a bit of support to make it simpler to produce DECFLOAT values with less digits or with a smaller exponent.

Commented by: @dyemanov

This way one could also suggest smallint '1', bigint '1', etc.

Commented by: @mrotteveel

Those values are easy to enter as normal literals.

Commented by: @dyemanov

In your case, the literal is parsed as NUMERIC but you want DECFLOAT. In my case, it's parsed as INT but I want BIGINT. I don't see a big difference here.

Commented by: @mrotteveel

But those literal values are convertible to bigint or smallint without loss of precision, the same can't be said for reasonable decfloat values. Say I want 2.33333e-32 as a decfloat value, I must use cast('2.33333e-32' as decfloat), otherwise I'll get a double precision with loss of precision. If that is then converted to DECFLOAT (eg assignment conversion), then the resulting value is 2.3333299999999999E-32

Being able to use DECFLOAT'2.33333e-32' or DECFLOAT '2.33333e-32' will be simpler and cause less visual clutter than a cast.

Commented by: @AlexPeshkoff

@ds - I fully agree with you, and I plan to fix DECFLOAT literals instead implementing this issue

Commented by: @sim1984

And my opinion is still on the side of Mark. There is nothing wrong with the server recognizing a literal as INT instead of BIGINT. However, if DOUBLE PRECISION is used instead of DECFLOAT, this means a loss of precision. You need a simple way to go to the calculations with high precision.

Commented by: @mrotteveel

Alex, fixing DECFLOAT literals how? I can't see a way to do that without breaking backwards compatibility for current behaviour of approximate numeric precision literals or exact numeric precision literals.

Commented by: @AlexPeshkoff

Use of any datatype instead DECFLOAT may be wrong - for example, 2 & 2.00 are distinct things from decfloat POV. When using int to represent them you loose precision info.

How to fix - I will be able to exactly answer this after the fix.

Commented by: @mrotteveel

From the SQL standard perspective, the only option is to redefine the approximate numeric precision literals to decfloat instead of double precision. Redefining the exact numeric precision literals to DECFLOAT would not be 'correct'.

See SQL:2016-2 section 4.4:

"""
An <approximate numeric literal> ANL consists of a <mantissa> that is an <exact numeric literal>, the letter 'E' or 'e', and an <exponent> that is a <signed integer>. It is implementation-defined whether the declared type of ANL is an approximate numeric type or the decimal floating-point type.
"""

and section 5.3, syntax rules:

"""
22) The declared type of an <exact numeric literal> ENL is an implementation-defined exact numeric type whose scale is the number of <digit>s to the right of the <period>. There shall be an exact numeric type capable of representing the value of ENL exactly.

23) It is implementation-defined whether the declared type of an <approximate numeric literal> ANL is an implementation-defined approximate numeric type or the decimal floating-point type with an implementation-defined precision. If the declared type of ANL is an approximate numeric type, then the value of ANL shall not be greater than the maximum value nor less than the minimum value that can be represented by the approximate numeric types. If the declared type of ANL is the decimal floating-point type, then the value of ANL shall not be greater than the maximum value nor less than the minimum value that can be represented by the decimal floating-point type.
"""