[
https://issues.jboss.org/browse/TEIID-1600?page=com.atlassian.jira.plugin...
]
Steven Hawkins updated TEIID-1600:
----------------------------------
Summary: Exact numeric (was: Exact numerical literal parsing)
Description:
Teiid diverges from the SQL spec by parsing numerical expressions of the form <integral
value>.<integral value> as doubles rather than as an exact numeric type (which
for us would be BigDecimal). I believe this was originally done to match Java parsing
semantics and potentially to avoid performance overhead of using BigBecimal. However this
can lead to a loss of precision that is not expected by ANSI SQL.
inexact numeric values entered in scientific notation would not be affected by this
change. They would still be parsed as doubles.
The SQL spec also requires that the result of AVG on an exact type be returned as an exact
type (although precision and scale are implementation dependent).
was:
Teiid diverges from the SQL spec by parsing numerical expressions of the form <integral
value>.<integral value> as doubles rather than as an exact numeric type (which
for us would be BigDecimal). I believe this was originally done to match Java parsing
semantics and potentially to avoid performance overhead of using BigBecimal. However this
can lead to a loss of precision that is not expected by ANSI SQL.
inexact numeric values entered in scientific notation would not be affected by this
change. They would still be parsed as doubles.
A system property could be introduced, org.teiid.AnsiExactNumeric that could change the
parsing/resolving behavior to be inline with the spec. This could be added prior to 8.0.
Exact numeric
-------------
Key: TEIID-1600
URL:
https://issues.jboss.org/browse/TEIID-1600
Project: Teiid
Issue Type: Bug
Components: Query Engine
Reporter: Steven Hawkins
Assignee: Steven Hawkins
Fix For: 8.0
Teiid diverges from the SQL spec by parsing numerical expressions of the form
<integral value>.<integral value> as doubles rather than as an exact numeric
type (which for us would be BigDecimal). I believe this was originally done to match Java
parsing semantics and potentially to avoid performance overhead of using BigBecimal.
However this can lead to a loss of precision that is not expected by ANSI SQL.
inexact numeric values entered in scientific notation would not be affected by this
change. They would still be parsed as doubles.
The SQL spec also requires that the result of AVG on an exact type be returned as an
exact type (although precision and scale are implementation dependent).
--
This message is automatically generated by JIRA.
For more information on JIRA, see:
http://www.atlassian.com/software/jira