From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | Zoltan Boszormenyi <zb(at)cybertec(dot)at> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Florian G(dot) Pflug" <fgp(at)phlo(dot)org>, Bruce Momjian <bruce(at)momjian(dot)us>, List pgsql-patches <pgsql-patches(at)postgresql(dot)org> |
Subject: | Re: [HACKERS] Re: IDENTITY/GENERATED v36 Re: Final version of IDENTITY/GENERATED patch |
Date: | 2007-04-17 02:11:08 |
Message-ID: | 46242CBC.9090407@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
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.
cheers
andrew
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2007-04-17 02:44:30 | Re: Grantor name gets lost when grantor role dropped |
Previous Message | Jeff Davis | 2007-04-17 01:59:40 | Grantor name gets lost when grantor role dropped |
From | Date | Subject | |
---|---|---|---|
Next Message | Robins Tharakan | 2007-04-17 03:24:15 | Fwd: Strangely Variable Query Performance |
Previous Message | Alvaro Herrera | 2007-04-16 23:01:04 | Re: [HACKERS] choose_bitmap_and again (was Re: [PERFORM] Strangely Variable Query Performance) |