
Tom, can you see anything wrong with this y.output file that would cause
it not to parse a plain create table statement?

ftp://ftp.tech.com.au/pub/y.output.gz
ftp://ftp.tech.com.au/pub/gram.y.gz

foo=# create table aa (bb text);
ERROR:  parser: parse error at or near "text"
ERROR:  parser: parse error at or near "text"
foo=#

Thu, 25 May 2000 23:06:37 +1000
Chris Bitmead <chris@bitmead.com>
gram.y PROBLEM with UNDER
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

Thu, 25 May 2000 11:46:31 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: gram.y PROBLEM with UNDER 
> 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.

Yes, even I don't apply those, though they say I never met a patch I
didn't like.  :-)

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Thu, 25 May 2000 12:12:12 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Re: gram.y PROBLEM with UNDER
On Thu, May 25, 2000 at 12:12:12PM -0400, Bruce Momjian wrote:
> > 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.
> 
> Yes, even I don't apply those, though they say I never met a patch I
> didn't like.  :-)

Bruce, your going to _make_ me grovel through the archives, and prove
that you were the first one to say that aren't you?

Ross
;-)

Thu, 25 May 2000 15:39:23 -0500
"Ross J. Reedstrom" <reedstrm@rice.edu>
Re: Re: gram.y PROBLEM with UNDER
> On Thu, May 25, 2000 at 12:12:12PM -0400, Bruce Momjian wrote:
> > > 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.
> > 
> > Yes, even I don't apply those, though they say I never met a patch I
> > didn't like.  :-)
> 
> Bruce, your going to _make_ me grovel through the archives, and prove
> that you were the first one to say that aren't you?

I believe it was a Thomas Lockhart line.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Thu, 25 May 2000 16:49:21 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Re: gram.y PROBLEM with UNDER
On Thu, May 25, 2000 at 04:49:21PM -0400, Bruce Momjian wrote:
> > > 
> > > Yes, even I don't apply those, though they say I never met a patch I
> > > didn't like.  :-)
> > 
> > Bruce, your going to _make_ me grovel through the archives, and prove
> > that you were the first one to say that aren't you?
> 
> I believe it was a Thomas Lockhart line.

O.K., first one _I_ saw say that. 

Ross
P.S. you do all us occasional patchers a great service. Don't change a
thing ;-)

Thu, 25 May 2000 18:02:00 -0500
"Ross J. Reedstrom" <reedstrm@rice.edu>
Re: Re: gram.y PROBLEM with UNDER
> On Thu, May 25, 2000 at 04:49:21PM -0400, Bruce Momjian wrote:
> > > > 
> > > > Yes, even I don't apply those, though they say I never met a patch I
> > > > didn't like.  :-)
> > > 
> > > Bruce, your going to _make_ me grovel through the archives, and prove
> > > that you were the first one to say that aren't you?
> > 
> > I believe it was a Thomas Lockhart line.
> 
> O.K., first one _I_ saw say that. 
> 
> Ross
> P.S. you do all us occasional patchers a great service. Don't change a
> thing ;-)

I am always ready to back stuff out if someone objects.   People
certainly like quick patch application.  Makes them feel we value their
contributions, which we do.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Thu, 25 May 2000 19:15:59 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Re: gram.y PROBLEM with UNDER
Tom Lane wrote:
> 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.

I thought shift/reduce conflicts were part and parcel of most language
syntaxes. reduce/reduce being rather more naughty. The standard syntax
already produces 95 shift/reduce conflicts. Can you clarify about
unresolved conflicts not being accepted?

Fri, 26 May 2000 11:14:09 +1000
Chris Bitmead <chrisb@nimrod.itg.telstra.com.au>
Re: gram.y PROBLEM with UNDER
> Tom Lane wrote:
> > 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.
> 
> I thought shift/reduce conflicts were part and parcel of most language
> syntaxes. reduce/reduce being rather more naughty. The standard syntax
> already produces 95 shift/reduce conflicts. Can you clarify about
> unresolved conflicts not being accepted?

What?  I get zero here.  shift/reduce is sloppy programming.  We don't
do that here.  :-)

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Thu, 25 May 2000 21:31:55 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Re: gram.y PROBLEM with UNDER
Bruce Momjian wrote:
> 
> > Tom Lane wrote:
> > > 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.
> >
> > I thought shift/reduce conflicts were part and parcel of most language
> > syntaxes. reduce/reduce being rather more naughty. The standard syntax
> > already produces 95 shift/reduce conflicts. Can you clarify about
> > unresolved conflicts not being accepted?
> 
> What?  I get zero here.  shift/reduce is sloppy programming.  We don't
> do that here.  :-)

Hmm. Now I look, I think that was with an older pgsql. Maybe 6.5 or
something. Have you guys done some black magic to get rid of them?

Fri, 26 May 2000 12:06:44 +1000
Chris Bitmead <chrisb@nimrod.itg.telstra.com.au>
Re: Re: gram.y PROBLEM with UNDER
Chris Bitmead <chrisb@nimrod.itg.telstra.com.au> writes:
>> 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.

> I thought shift/reduce conflicts were part and parcel of most language
> syntaxes. reduce/reduce being rather more naughty. The standard syntax
> already produces 95 shift/reduce conflicts. Can you clarify about
> unresolved conflicts not being accepted?

What's to clarify?  The existing grammar does produce a long list of
*resolved* conflicts, which are not very interesting (they just indicate
that we are using operator precedence rules instead of creating a
detailed grammar for expressions).  Unresolved conflicts are a far
more serious problem, because they tell you that there is an unreachable
part of your language.  As indeed was happening to you in this case.

			regards, tom lane

Thu, 25 May 2000 22:09:17 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: Re: gram.y PROBLEM with UNDER 
> Bruce Momjian wrote:
> > 
> > > Tom Lane wrote:
> > > > 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.
> > >
> > > I thought shift/reduce conflicts were part and parcel of most language
> > > syntaxes. reduce/reduce being rather more naughty. The standard syntax
> > > already produces 95 shift/reduce conflicts. Can you clarify about
> > > unresolved conflicts not being accepted?
> > 
> > What?  I get zero here.  shift/reduce is sloppy programming.  We don't
> > do that here.  :-)
> 
> Hmm. Now I look, I think that was with an older pgsql. Maybe 6.5 or
> something. Have you guys done some black magic to get rid of them?
> 

They have not been there for _years_.  I see lots of open source stuff
with shift/reduce reports.  We don't.  It is tricky to remove them.  It
often involves adding duplicate actions to prevent the problems. 
Certain people are quite good at it, and are glad to help.


-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Thu, 25 May 2000 22:15:41 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Re: gram.y PROBLEM with UNDER