Github user zellerh commented on a diff in the pull request:
https://github.com/apache/incubator-trafodion/pull/577#discussion_r70656018
--- Diff: core/sql/parser/sqlparser.y ---
@@ -14684,6 +14759,11 @@ optional_limit_spec : TOK_LIMIT
NUMERIC_LITERAL_EXACT_NO_SCALE
dml_statement : dml_query { $$ = $1; }
+ | with_clause_list dml_query
--- End diff --
Yes, I got a similar result. I tried this:
query_expression : with_clause non_join_query_expression
| non_join_query_expression
That gives me three additional reduce/reduce conflicts which I don't
understand. Here are two of them:
State 1941
1870 query_expression: with_clause non_join_query_expression .
1871 | non_join_query_expression .
TOK_EXCEPT reduce using rule 1870 (query_expression)
TOK_EXCEPT [reduce using rule 1871 (query_expression)]
TOK_UNION reduce using rule 1870 (query_expression)
TOK_UNION [reduce using rule 1871 (query_expression)]
$default reduce using rule 1870 (query_expression)
I also tried this:
query_expression : optional_with_clause non_join_query_expression
That doesn't cause additional reduce/reduce conflicts, but we get a very
large number of additional shift/reduce conflicts, something in the
neighborhood of 50-100.
If we can't get the "correct" parser rules to work, then maybe we can stick
with the approach you chose (assuming it accepts all the valid WITH clauses)
and handle any illegal syntax in the semantic actions.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---
