[
https://issues.apache.org/jira/browse/CALCITE-4081?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17142557#comment-17142557
]
Danny Chen edited comment on CALCITE-4081 at 6/23/20, 2:37 AM:
---------------------------------------------------------------
The code comment says:
{code:xml}
Decimal and long have the same precision
{code}
The SQL standard 2011 IWD 9057-2:2011(E) 6.1 <data type> says that:
{code:xml}
25) For the <exact numeric type>s DECIMAL and NUMERIC:
a) The maximum value of <precision> is implementation-defined. <precision>
shall not be greater than this value.
b) The maximum value of <scale> is implementation-defined. <scale> shall
not be greater than this maximum value.
{code}
It seems that decimal max precision is system specific, a validation in the
parser seems not reasonable. And very probably the unscaled BigInteger exceeds
the precision of Java long.
was (Author: danny0405):
The code comment says:
{code:java}
Decimal and long have the same precision
{code}
The SQL standard 2011 IWD 9057-2:2011(E) 6.1 <data type> says that:
{code:java}
25) For the <exact numeric type>s DECIMAL and NUMERIC:
a) The maximum value of <precision> is implementation-defined.
<precision> shall not be greater than
this value.
b) The maximum value of <scale> is implementation-defined. <scale> shall
not be greater than this
maximum value.
{code}
It seems that decimal max precision is system specific, a validation in the
parser seems not reasonable. And very probably the unscaled BigInteger exceeds
the precision of Java long.
> Round-tripping a DECIMAL literal through Planner -> RelToSqlConverter ->
> Planner throws validation error
> --------------------------------------------------------------------------------------------------------
>
> Key: CALCITE-4081
> URL: https://issues.apache.org/jira/browse/CALCITE-4081
> Project: Calcite
> Issue Type: Bug
> Reporter: Steven Talbot
> Priority: Major
>
> Take the following SQL:
> SELECT CAST('11111111111111111111111111111111.111111' AS DECIMAL(38,6)) AS
> "num"
> And, in the default Calcite SQL dialect with all defaults, send it through
> Planner parse -> valiate -> rel to get a RelNode. The RelNode will have a
> Project with the "111111111111111.11111" literal in there as a RexLiteral
> with Decimal type.
>
> The use RelToSqlConverter to convert that RelNode back to SQL. The SQL now
> looks like
> SELECT 11111111111111111111111111111111.111111 AS "num"
>
> If you attempt to parse and validate that SQL, you get "Numeric literal
> '11111111111111111111111111111111.111111' out of range" throw by
> SqlValidatorImpl.validateLiteral()
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
