Re: Row expression parse problem

[Shuyi Chen]

Thanks for raising the issue. I did remember seeing this problem before.
I've created a JIRA <https://issues.apache.org/jira/browse/CALCITE-2276> to
log the issue.

On Mon, Apr 23, 2018 at 7:29 AM, Julian Hyde <jhyde.apa...@gmail.com> wrote:

> I agree, this looks like a bug.
>
> Julian
>
> > On Apr 23, 2018, at 05:03, 陈硕清 <yyxcsq0...@gmail.com> 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?
>



-- 
"So you have to trust that the dots will somehow connect in your future."