Currently Firebird has two documented floating point datatypes:
- FLOAT (a 32 bit single precision)
- DOUBLE PRECISION (a 64 bit double precision)
Firebird also has the - undocumented - datatypes
- REAL (a 32 bit single precision), essentially an alias for FLOAT. REAL
is a SQL standard type.
- LONG FLOAT (a 64 bit double precision), essentially an alias for
DOUBLE PRECISION
In addition, Firebird supports - again, undocumented - FLOAT(p) with p
in decimal precision, where
- p in [0,7] is a 32 bit single precision float
- p in [8,..) is a 64 bit double precision float
The SQL standard however defines FLOAT differently. From SQL:2016 6.1
<data type>:
"""
Syntax Rules
20) If a <precision> is omitted, then an implementation-defined
<precision> is implicit.
21) The value of a <precision> shall be greater than 0 (zero). [..]
[..]
29) FLOAT specifies the data type approximate numeric, with binary
precision equal to or greater than the value of the specified
<precision>. The maximum value of <precision> is implementation-defined.
<precision> shall not be greater than this value.
30) REAL specifies the data type approximate numeric, with
implementation-defined precision.
31) DOUBLE PRECISION specifies the data type approximate numeric, with
implementation-defined precision that is greater than the
implementation-defined precision of REAL.
32) For the <approximate numeric type>s FLOAT, REAL, and DOUBLE
PRECISION, the maximum and minimum values of the exponent are
implementation-defined.
"""
I propose that for Firebird 4 we bring this inline with the standard:
1. Change and document FLOAT(p) to apply precision in binary digits,
that is:
- p in [1, 24] is a 32 bit single precision
- p in [25, 53] is a 64 bit double precision
- p < 1 and p > 53 are an error (in the future we could consider adding
support for higher precision formats like binary128 (p in [54, 113]) and
binary256 (p in [114, 237]))
2. Document that FLOAT (without precision) is a synonym for FLOAT(24).
3. Document DOUBLE PRECISION as a synonym of FLOAT(53)
4. Document REAL as a synonym of FLOAT(24)
5. Document LONG FLOAT as a synonym of FLOAT(53)
This change will break backwards compatibility for FLOAT(p), but as the
precision syntax for FLOAT was never documented, I think that is an
acceptable tradeoff to gain better standard compliance.
As far as I can tell, technically this change would be limited to
parse.y (float_type).
Are there any objections to such a change? I'm willing to provide a pull
request for this.
Mark
--
Mark Rotteveel
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
