[ 
https://issues.apache.org/jira/browse/CALCITE-7763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18118647#comment-18118647
 ] 

Guanyu Chen commented on CALCITE-7763:
--------------------------------------

I think according to the current patterns and structures, it would be hard and 
need some refactoring. The validator reads sourceSelect back through the 
original node reference. We cannot eliminate that mutation without touching all 
downstream code.

Also, since other classes like {{SqlWith}}, {{SqlMerge}}, etc., they don't have 
the {{final}} decorator for the variables as well so I hope that making the 
fields mutable is ok.

> "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)

Reply via email to