[
https://issues.apache.org/jira/browse/CALCITE-7763?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde updated CALCITE-7763:
---------------------------------
Description:
{{TABLE t ORDER BY c}} and {{(SELECT ... LIMIT n) ORDER BY c}} fail with
{{{}UnsupportedOperationException{}}}.
{{SqlOrderBy}} has final fields and does not override
{{{}setOperand{}}}, so {{SqlCall.setOperand}} throws. But
{{SqlValidatorImpl.performUnconditionalRewrites}} rewrites operands before the
node itself and writes the result back with {{{}call.setOperand(i,
newOperand){}}}. Any query whose {{ORDER BY}} / {{LIMIT}} / {{OFFSET}} /
{{FETCH}} wraps a node that is itself rewritten — an
EXPLICIT_TABLE, or a nested {{SqlOrderBy}} from a parenthesized query —
therefore fails validation with an internal error.
Here is a test case, {{test.iq}}:
{code:java}
!use scott
select * from emp;
!ok
table emp order by empno;
!ok
table emp limit 5;
!ok
(select * from emp limit 5) order by empno;
!ok
(select * from emp order by ename) limit 5;
!ok
(select * from emp limit 5) order by empno;
!ok {code}
The first query succeeds and the rest all throw
{noformat}
java.lang.UnsupportedOperationException
at org.apache.calcite.sql.SqlCall.setOperand(SqlCall.java:71)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.performUnconditionalRewrites(SqlValidatorImpl.java:1853)
{noformat}
The query "{{{}values (1), (2) order by 1{}}}" survives only because {{VALUES}}
is explicitly exempted from rewriting.
Discovered while investigating CALCITE-7761.
was:
{{TABLE t ORDER BY c}} and {{(SELECT ... LIMIT n) ORDER BY c}} fail with
{{{}UnsupportedOperationException{}}}.
{{SqlOrderBy}} has final fields and does not override
{{{}setOperand{}}}, so {{SqlCall.setOperand}} throws. But
{{SqlValidatorImpl.performUnconditionalRewrites}} rewrites operands before the
node itself and writes the result back with {{{}call.setOperand(i,
newOperand){}}}. Any query whose {{ORDER BY}} / {{LIMIT}} / {{OFFSET}} /
{{FETCH}} wraps a node that is itself rewritten — an
EXPLICIT_TABLE, or a nested {{SqlOrderBy}} from a parenthesized query —
therefore fails validation with an internal error.
Here is a test case, {{{}test.iq{}}}:
{code:java}
!use scott
select * from emp;
!ok
table emp;
!ok
table emp order by empno;
!ok
table emp limit 5;
!ok
(select * from emp limit 5) order by empno;
!ok
(select * from emp order by ename) limit 5;
!ok
(select * from emp limit 5) order by empno;
!ok {code}
The first query succeeds and the rest all throw
{noformat}
java.lang.UnsupportedOperationException
at org.apache.calcite.sql.SqlCall.setOperand(SqlCall.java:71)
at
org.apache.calcite.sql.validate.SqlValidatorImpl.performUnconditionalRewrites(SqlValidatorImpl.java:1853)
{noformat}
The query "{{{}values (1), (2) order by 1{}}}" survives only because {{VALUES}}
is explicitly exempted from rewriting.
Discovered while investigating CALCITE-7761.
> "TABLE t ORDER BY c" and "(SELECT ... LIMIT n) ORDER BY c" fail with
> UnsupportedOperationException
> --------------------------------------------------------------------------------------------------
>
> Key: CALCITE-7763
> URL: https://issues.apache.org/jira/browse/CALCITE-7763
> Project: Calcite
> Issue Type: Bug
> Reporter: Julian Hyde
> Priority: Major
>
> {{TABLE t ORDER BY c}} and {{(SELECT ... LIMIT n) ORDER BY c}} fail with
> {{{}UnsupportedOperationException{}}}.
>
> {{SqlOrderBy}} has final fields and does not override
> {{{}setOperand{}}}, so {{SqlCall.setOperand}} throws. But
> {{SqlValidatorImpl.performUnconditionalRewrites}} rewrites operands before
> the node itself and writes the result back with {{{}call.setOperand(i,
> newOperand){}}}. Any query whose {{ORDER BY}} / {{LIMIT}} / {{OFFSET}} /
> {{FETCH}} wraps a node that is itself rewritten — an
> EXPLICIT_TABLE, or a nested {{SqlOrderBy}} from a parenthesized query —
> therefore fails validation with an internal error.
>
> Here is a test case, {{test.iq}}:
> {code:java}
> !use scott
> select * from emp;
> !ok
> table emp order by empno;
> !ok
> table emp limit 5;
> !ok
> (select * from emp limit 5) order by empno;
> !ok
> (select * from emp order by ename) limit 5;
> !ok
> (select * from emp limit 5) order by empno;
> !ok {code}
> The first query succeeds and the rest all throw
> {noformat}
> java.lang.UnsupportedOperationException
> at org.apache.calcite.sql.SqlCall.setOperand(SqlCall.java:71)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.performUnconditionalRewrites(SqlValidatorImpl.java:1853)
> {noformat}
> The query "{{{}values (1), (2) order by 1{}}}" survives only because
> {{VALUES}} is explicitly exempted from rewriting.
> Discovered while investigating CALCITE-7761.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
