Re: gram.y PROBLEM with UNDER - Mailing list pgsql-hackers

Chris Bitmead <chris@bitmead.com> writes:
> Tom, can you see anything wrong with this y.output file that would cause
> it not to parse a plain create table statement?

Uh, you've got a ton of unresolved conflicts there:

State 17 contains 1 shift/reduce conflict.
State 257 contains 1 shift/reduce conflict.
State 359 contains 4 shift/reduce conflicts.
State 595 contains 1 shift/reduce conflict.
State 1106 contains 2 reduce/reduce conflicts.
State 1260 contains 127 shift/reduce conflicts.
State 1484 contains 2 reduce/reduce conflicts.
State 1485 contains 2 reduce/reduce conflicts.
State 1486 contains 2 reduce/reduce conflicts.

If you don't get rid of those then your parser will behave in surprising
ways.  So far you have noticed the fallout from only one of those
conflicts, but every one of them is a potential bug.  Be advised that
gram.y patches that create unresolved conflicts will *not* be accepted.

The immediate problem you are seeing seems to be the conflict in state
595:

state 595
   CreateStmt  ->  CREATE OptTemp TABLE relation_name . OptUnder '(' OptTableElementList ')' OptInherit   (rule 151)
CreateAsStmt ->  CREATE OptTemp TABLE relation_name . OptCreateAs AS SelectStmt   (rule 207)
 
   UNDER       shift, and go to state 807   '('         shift, and go to state 808
   '('         [reduce using rule 204 (OptUnder)]   $default    reduce using rule 209 (OptCreateAs)
   OptUnder    go to state 809   OptCreateAs go to state 810

which is going to be a tad tricky to get around: you will need to
restructure the productions so that the thing doesn't have to decide
whether to reduce an empty OptUnder before parsing the contents of the
parenthesized list.  It's only by looking to see if that list contains
columndefs or just bare names that the parser can tell whether it's
dealing with CREATE or CREATE AS; you are forcing it to make a decision
between the two rules sooner than that, and can hardly complain that it
picked the wrong one at random.

Maybe the simplest answer is to put OptUnder into the same position in
the CREATE AS production (and then reject a nonempty OptUnder in the
action for that rule, unless you want to try to support it...).  That
way there's no conflict between the two rules up till the point where
the parser can resolve the difference between them.

Offhand it looks like most of the other complaints arise because you've
provided two different parsing paths for 'ONLY relationname'.
        regards, tom lane