git.net

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Row expression parse problem


I agree, this looks like a bug. 

Julian

> On Apr 23, 2018, at 05:03, 陈硕清 <yyxcsq0225@xxxxxxxxx> wrote:
> 
> Dear all:
> 
> Now for our production, we can parse a query successfully like this :
> 
> -- 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'
> 
> 
> but if we add in `Row`:
> 
> -- 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'
> 
> 
> 
> it will throw exception:
> 
> 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
> 
> For the success query, if we exec parsed AST tree rootNode.toString(), it
> will return a query like:
> 
> 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'
> 
> 
> This is inconsistent  by Calcite itself semantic.
> 
> 
> So guys, should we support explicit  Row like for the failure one?