[
https://issues.apache.org/jira/browse/CALCITE-35?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15875205#comment-15875205
]
Julian Hyde commented on CALCITE-35:
------------------------------------
It is difficult to fix this. The following comment from
[Parser.jj|https://github.com/apache/calcite/blob/beb465334c1bdc62b8282492ad7580c0683cee01/core/src/main/codegen/templates/Parser.jj#L346]
explains:
{quote}
NOTE jvs 6-Feb-2004: The straightforward way to implement the SQL grammar is
to keep query expressions (SELECT, UNION, etc) separate from row expressions
(+, LIKE, etc). However, this is not possible with an LL(k) parser, because
both kinds of expressions allow parenthesization, so no fixed amount of left
context is ever good enough. A sub-query can be a leaf in a row expression,
and can include operators like UNION, so it's not even possible to use a
syntactic lookahead rule like "look past an indefinite number of parentheses
until you see SELECT, VALUES, or TABLE" (since at that point we still
don't know whether we're parsing a sub-query like ((select ...) + x)
vs. (select ... union select ...).
The somewhat messy solution is to unify the two kinds of expression,
and to enforce syntax rules using parameterized context. This
is the purpose of the ExprContext parameter. It is passed to
most expression productions, which check the expressions encountered
against the context for correctness. When a query
element like SELECT is encountered, the production calls
checkQueryExpression, which will throw an exception if
a row expression was expected instead. When a row expression like
IN is encountered, the production calls checkNonQueryExpression
instead. It is very important to understand how this works
when modifying the grammar.
The commingling of expressions results in some bogus ambiguities which are
resolved with LOOKAHEAD hints. The worst example is comma. SQL allows both
(WHERE x IN (1,2)) and (WHERE x IN (select ...)). This means when we parse
the right-hand-side of an IN, we have to allow any kind of expression inside
the parentheses. Now consider the expression "WHERE x IN(SELECT a FROM b
GROUP BY c,d)". When the parser gets to "c,d" it doesn't know whether the
comma indicates the end of the GROUP BY or the end of one item in an IN
list. Luckily, we know that select and comma-list are mutually exclusive
within IN, so we use maximal munch for the GROUP BY comma. However, this
usage of hints could easily mask unintended ambiguities resulting from
future changes to the grammar, making it very brittle.
{quote}
> Support parenthesized sub-clause in JOIN
> ----------------------------------------
>
> Key: CALCITE-35
> URL: https://issues.apache.org/jira/browse/CALCITE-35
> Project: Calcite
> Issue Type: Bug
> Reporter: GitHub Import
> Labels: github-import
>
> SQL-92 allows joins to be grouped into trees using parentheses. For example,
> select * from a join (b join c on b.x = c.x) on a.y = c.y
> Optiq should support this. Currently this gives
> "org.eigenbase.util.EigenbaseException: Non-query expression encountered in
> illegal context".
> ---------------- Imported from GitHub ----------------
> Url: https://github.com/julianhyde/optiq/issues/35
> Created by: [julianhyde|https://github.com/julianhyde]
> Labels:
> Created at: Fri Apr 19 02:46:01 CEST 2013
> State: open
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
