Recursive query syntax ambiguity

Gregory Stark wrote:

Woah, I just realized it's much worse than that. I think the syntax in the
ANSI is not parsable in LALR(1) at all. Note the following:

WITH RECURSIVE foo (a,b) AS (subq) SEARCH BREADTH FIRST BY a,b,c(x,z),d(y,z) AS (subq) SELECT ...

To determine whether "c" is the name of a new <with list element> it has to
scan as far ahead as the "," before the "d". Note that "d" here is in fact not
part of the <search clause> at all, it's the name of a second <with list
element>.

bleagh.

Can you post the rules you have so far that you're playing around with?
(Also maybe the rules from the standard - I don't have a copy handy).

cheers

andrew

"Andrew Dunstan" <andrew@dunslane.net> writes:

Can you post the rules you have so far that you're playing around with? (Also
maybe the rules from the standard - I don't have a copy handy).

This is the best compromise I've come up with so far. It makes CYCLE a
reserved word and requires a CYCLE clause if there's a SEARCH clause.

Ok, looking at your example:

WITH RECURSIVE foo (a,b) AS (subq) SEARCH BREADTH FIRST BY a,b , c(x,z),d(y,z) AS (subq) SELECT ...

What you're trying to say is that the c is a <with list element>,
not a <cycle column>. But the parser will see that as soon as it hits
the open parenthesis, since a <cycle column> is always just a column
name.

Also, the AS is the <with list element> doesn't appear to be optional,
I assume you left that out after the c(x,z) for clarity.

I think bison should be able to handle this as long as the "name" in
common_table_expression matches exactly the same things as whatever
columnList uses. It can the merge the two parse paths, allowing it to
"see" further.

Have a nice day,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/