Thread: gram.y PROBLEM with UNDER
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=#
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
> 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, Pennsylvania19026
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 ;-)
> 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, Pennsylvania19026
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 ;-)
> 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, Pennsylvania19026
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?
> 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, Pennsylvania19026
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
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?
> 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, Pennsylvania19026