[
https://issues.apache.org/jira/browse/IMPALA-13568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18022257#comment-18022257
]
Steve Carlin commented on IMPALA-13568:
---------------------------------------
Gonna close this and open a new Jira for next release specifically for the
"values" clause support
> Calcite planner is falling back incorrectly for some select statements
> ----------------------------------------------------------------------
>
> Key: IMPALA-13568
> URL: https://issues.apache.org/jira/browse/IMPALA-13568
> Project: IMPALA
> Issue Type: Sub-task
> Components: Frontend
> Affects Versions: Impala 4.5.0
> Reporter: Joe McDonnell
> Assignee: Steve Carlin
> Priority: Major
>
> The Calcite planner tries to parse with the Calcite parser. If that fails, it
> checks whether this is a select statement by parsing with the regular parser
> and seeing if it is a SelectStmt. If it isn't, it falls back to the original
> planner. This is great for DDL/DML and other random statements not supported
> by Calcite, but this check is not quite right. This statement is a select,
> but it falls back to the original planner:
> {noformat}
> with t1 as (select int_col x, bigint_col y from alltypestiny),
> t2 as (select 1 x , 10 y), t3 as (values(2 x , 20 y), (3, 30))
> select * from t1 union all select * from t2 union all (select * from t3)
> order by x limit 20{noformat}
> The check should be comparing against QueryStmt, which is the base class for
> SelectStmt as well as SetOperationsStmt and UnionStmt.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
