On 27-7-2019 14:35, Mark Rotteveel wrote:
On 27-7-2019 14:16, Adriano dos Santos Fernandes wrote:
On 27/07/2019 07:57, Mark Rotteveel wrote:
When working on my pull request for FLOAT, I noticed that the way that
the precision fragments (ie precision_opt and precision_opt_nz) works in
the gramma
On 27-7-2019 14:16, Adriano dos Santos Fernandes wrote:
On 27/07/2019 07:57, Mark Rotteveel wrote:
When working on my pull request for FLOAT, I noticed that the way that
the precision fragments (ie precision_opt and precision_opt_nz) works in
the grammar yields non-intuitive error messages.
For
On 27/07/2019 07:57, Mark Rotteveel wrote:
> When working on my pull request for FLOAT, I noticed that the way that
> the precision fragments (ie precision_opt and precision_opt_nz) works in
> the grammar yields non-intuitive error messages.
>
> For example, a negative precision just yields an unc
When working on my pull request for FLOAT, I noticed that the way that
the precision fragments (ie precision_opt and precision_opt_nz) works in
the grammar yields non-intuitive error messages.
For example, a negative precision just yields an unclear
"""
Token unknown - line 10, column 20
-
"""
On 22-7-2019 11:18, Dmitry Yemanov wrote:
13.07.2019 12:10, Mark Rotteveel wrote:
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
Changing FLOAT to a SQL standard compliant FLOAT datatype
-
Key: CORE-6109
URL: http://tracker.firebirdsql.org/browse/CORE-6109
Project: Firebird Core
Issue Type: New Feature
