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

From Zoltan Boszormenyi
Subject Re: [HACKERS] Re: IDENTITY/GENERATED v36 Re: Final version of IDENTITY/GENERATED patch
Date
Msg-id 4623FB1A.5050605@cybertec.at
Whole thread Raw
In response to Re: Final version of IDENTITY/GENERATED patch  (Bruce Momjian <bruce@momjian.us>)
Responses Re: [HACKERS] Re: IDENTITY/GENERATED v36 Re: Final version of IDENTITY/GENERATED patch  (Andrew Dunstan <andrew@dunslane.net>)
List pgsql-patches
Zoltan Boszormenyi írta:
> Andrew Dunstan írta:
>> Florian G. Pflug wrote:
>>>>>>
>>>>>> bison -y -d  gram.y
>>>>>> conflicts: 2 shift/reduce
>>>
>>> I'ts been quite a time since I last used bison, but as far as I
>>> remember, you can tell it to write a rather details log about
>>> it's analysis of the grammar. That log should include more
>>> detailed information about those conflicts - maybe that helps
>>> to figure out their exact cause, and to find a workaround.
>>>
>>
>> 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.)
>>
>> cheers
>>
>> andrew
>
> 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.

Best regards,
Zoltán

--
----------------------------------
Zoltán Böszörményi
Cybertec Geschwinde & Schönig GmbH
http://www.postgresql.at/


Attachment

pgsql-patches by date:

Previous
From: Steve
Date:
Subject: Re: [HACKERS] choose_bitmap_and again (was Re: [PERFORM] Strangely Variable Query Performance)
Next
From: "Simon Riggs"
Date:
Subject: Re: scrollable cursor support without MOVE statement