[
https://issues.apache.org/jira/browse/CALCITE-4608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17352087#comment-17352087
]
Julian Hyde commented on CALCITE-4608:
--------------------------------------
Going a bit further... do we even need to have two different kinds of numeric
literals? (Leaving aside how we represent that difference: using a boolean
field or DECIMAL vs DOUBLE data type.) I haven't checked the standard. But I
checked the code, and the only place we check is in validating OVER ... ROWS.
Experiment 1. I ran the query
{code:sql}
SELECT empno, sal,
SUM(sal) OVER (ORDER BY empno ROWS 2 PRECEDING) AS sum_sal
FROM Emp{code}
on Oracle, PostgreSQL, BigQuery, Calcite and changed "2" to "2.0", "2.5",
"2.6", "2e0", "2.5e0". Oracle and PostgreSQL accepted all variants; Calcite and
BigQuery succeeded for "2" but failed on the others.
Experiment 2. I also tried
{code:sql}
SELECT *
FROM Emp
ORDER BY deptno LIMIT 2{code}
on Oracle, PostgreSQL, BigQuery, Calcite and changed "2" to "2.0", "2.5",
"2.6", "2e0", "2.5e0". PostgreSQL succeeded on all (but rounded 2.5, 2.6 and
2.5e0 up to 3), Oracle and BigQuery failed to parse all except "2". Calcite
accepted "2" and "2e0".
Experiment 3. I ran
{code:sql}
SELECT *
FROM Emp
ORDER BY 2{code}
on Oracle, PostgreSQL, BigQuery, Calcite, and changed "2" to "2.0", "2.5",
"2.6", "2e0", "2.5e0". Calcite succeeded on all (sorting by column 2, ENAME, on
all). PostgreSQL and BigQuery failed on all but "2" (giving error 'non-integer
constant in ORDER BY'), Oracle succeeded on all (but rounded 2.6 to 3, sorting
by column 3, JOB).
My conclusions from the experiments:
* Calcite should only have one kind of numeric literal (i.e. we should care
about the value, but not how the value is formatted) and be more like
PostgreSQL in experiments 1 and 2;
* ORDER BY ordinal (experiment 3) is a very different case from the others,
and the lexical form of ordinal should matter.
> Fix NullPointerException in SqlNumericLiteral.isInteger()
> ---------------------------------------------------------
>
> Key: CALCITE-4608
> URL: https://issues.apache.org/jira/browse/CALCITE-4608
> Project: Calcite
> Issue Type: Bug
> Affects Versions: 1.26.0
> Reporter: Amrish Lal
> Assignee: Ruben Q L
> Priority: Major
> Labels: pull-request-available
> Fix For: 1.27.0
>
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> In 1.26, a NullPointerException is thrown in SqlNumericLiteral.isInteger(),
> due to "this.scale" being null. This can be reproduced by compiling SQL
> statement "SELECT * FROM testTable WHERE floatColumn >
> 1.7976931348623157E308".
> A null check was added through CALCITE-4199 to fix the NullPointerException;
> however, the root cause is that scale and precision are not being properly
> set in {{SqlLiteral.createApproxNumeric}} function which is called to handle
> {{APPROX_NUMERIC_LITERAL}} token.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
