You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@calcite.apache.org by "Julian Hyde (JIRA)" <ji...@apache.org> on 2018/05/09 16:54:00 UTC

[jira] [Resolved] (CALCITE-2276) Allow explicit ROW value constructor in SELECT clause and elsewhere

     [ https://issues.apache.org/jira/browse/CALCITE-2276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Julian Hyde resolved CALCITE-2276.
----------------------------------
       Resolution: Fixed
    Fix Version/s: 1.17.0

Fixed in [2a4f6c2c|http://git-wip-us.apache.org/repos/asf/calcite/commit/2a4f6c2c]. Thanks for the PR, [~danny0405]!

The new behavior is controlled by {{SqlConformance.allowExplicitRowValueConstructor}}.

> Allow explicit ROW value constructor in SELECT clause and elsewhere
> -------------------------------------------------------------------
>
>                 Key: CALCITE-2276
>                 URL: https://issues.apache.org/jira/browse/CALCITE-2276
>             Project: Calcite
>          Issue Type: Bug
>          Components: core
>            Reporter: Shuyi Chen
>            Assignee: Julian Hyde
>            Priority: Major
>             Fix For: 1.17.0
>
>
> Allow explicit ROW value constructor in SELECT clause and elsewhere. Now for our production, we can parse a query successfully like this :
> {code}
> -- correlated IN subquery
> -- TC 01.01
> SELECT t1a,
>        t1b,
>        t1h
> FROM   t1
> WHERE  ( t1a, t1h ) NOT IN (SELECT t2a,
>                                    t2h
>                             FROM   t2
>                             WHERE  t2a = t1a
>                             ORDER  BY t2a)
> AND t1a = 'val1a'
> {code}
> but if we add in `Row`:
> {code}
> -- correlated IN subquery
> -- TC 01.01
> SELECT t1a,
>        t1b,
>        t1h
> FROM   t1
> WHERE  ROW( t1a, t1h ) NOT IN (SELECT t2a,
>                                    t2h
>                             FROM   t2
>                             WHERE  t2a = t1a
>                             ORDER  BY t2a)
> AND t1a = 'val1a'
> {code}
>  it will throw exception:
> {noformat}
> Caused by: org.apache.calcite.sql.parser.SqlParseException: ROW expression
> encountered in illegal context
>   at org.apache.calcite.sql.parser.impl.SqlParserImpl.convertException(SqlParserImpl.java:351)
>   at org.apache.calcite.sql.parser.impl.SqlParserImpl.normalizeException(SqlParserImpl.java:133)
>   at org.apache.calcite.sql.parser.SqlParser.parseQuery(SqlParser.java:138)
>   at org.apache.calcite.sql.parser.SqlParser.parseStmt(SqlParser.java:163)
>   at org.apache.flink.table.calcite.FlinkPlannerImpl.parse(FlinkPlannerImpl.scala:81)
> ... 8 more
> {noformat}
> For the success query, if we exec parsed AST tree rootNode.toString(), it
> will return a query like:
> {code}
> SELECT `t1a`,
>        `t1b`,
>        `t1h`
> FROM `t1`
> WHERE ROW(`t1a`, `t1h`) NOT IN (SELECT `t2a`, `t2h`
>                                 FROM `t2`
>                                 WHERE `t2a` = `t1a`
>                                 ORDER BY `t2a`)
> AND `t1a` = 'val1a'
> {code}
> This is inconsistent  by Calcite itself semantic.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)