Re: [HACKERS] Re: IDENTITY/GENERATED v36 Re: Final version of IDENTITY/GENERATED patch
От | Andrew Dunstan |
---|---|
Тема | Re: [HACKERS] Re: IDENTITY/GENERATED v36 Re: Final version of IDENTITY/GENERATED patch |
Дата | |
Msg-id | 46242CBC.9090407@dunslane.net обсуждение исходный текст |
Ответ на | Re: [HACKERS] Re: IDENTITY/GENERATED v36 Re: Final version of IDENTITY/GENERATED patch (Zoltan Boszormenyi <zb@cybertec.at>) |
Ответы |
Re: [HACKERS] Re: IDENTITY/GENERATED v36 Re: Final version of IDENTITY/GENERATED patch
|
Список | 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 по дате отправления: