Zoltan Boszormenyi wrote:
>>> You can almost always get rid of shift/reduce conflicts by unwinding
>>> some of the productions - resist the temptation to factor the
>>> grammar. The effect of this is to eliminate places where the parser
>>> has to decide between shifting and reducing. (This is why, for
>>> example, almost all the "drop foo if exists" variants require
>>> separate productions rather than using opt_if_exists.)
>> Thanks. This idea solved one of the two shift/reduce conflicts.
>> But the other one can only be solved if I put GENERATED
>> into the reserved_keyword set. But the standard spec says
>> it's unreserved. Now what should I do with it?
> What should I do? Send it. :-)
> Someone more familiar with bison can hopefully fix it...
> Please, review.
Yeah, I had a brief look. It's a bit ugly - the remaining conflict is in
the b_expr rules. We do have the filtered_base_yylex() gadget - not
sure if that can disambiguate for us.
In response to
pgsql-hackers by date
|Next:||From: Alvaro Herrera||Date: 2007-04-17 02:44:30|
|Subject: Re: Grantor name gets lost when grantor role dropped|
|Previous:||From: Jeff Davis||Date: 2007-04-17 01:59:40|
|Subject: Grantor name gets lost when grantor role dropped|
pgsql-patches by date
|Next:||From: Robins Tharakan||Date: 2007-04-17 03:24:15|
|Subject: Fwd: Strangely Variable Query Performance|
|Previous:||From: Alvaro Herrera||Date: 2007-04-16 23:01:04|
|Subject: Re: [HACKERS] choose_bitmap_and again (was Re: [PERFORM] Strangely Variable Query Performance)|