Julian Hyde created CALCITE-7763:
------------------------------------
Summary: "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
{{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.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
