Re: [HACKERS] Re: IDENTITY/GENERATED v36 Re: Final version of IDENTITY/GENERATED patch - Mailing list pgsql-patches

From Andrew Dunstan
Subject Re: [HACKERS] Re: IDENTITY/GENERATED v36 Re: Final version of IDENTITY/GENERATED patch
Date
Msg-id 46242CBC.9090407@dunslane.net
Whole thread Raw
In response to Re: [HACKERS] Re: IDENTITY/GENERATED v36 Re: Final version of IDENTITY/GENERATED patch  (Zoltan Boszormenyi <zb@cybertec.at>)
Responses Re: [HACKERS] Re: IDENTITY/GENERATED v36 Re: Final version of IDENTITY/GENERATED patch  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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


pgsql-patches by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: [HACKERS] choose_bitmap_and again (was Re: [PERFORM] Strangely Variable Query Performance)
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] Re: IDENTITY/GENERATED v36 Re: Final version of IDENTITY/GENERATED patch