Re: operator exclusion constraints

Tom Lane wrote:
> This is a pretty common difficulty with empty-producing productions.
> The usual way around it is to eliminate the empty production by making
> the calling production a bit more redundant.  In this case, we can fix
> it by replacing
>
> alter_table_cmd:
>             ADD_P opt_column columnDef
>
> with two productions
>
> alter_table_cmd:
>             ADD_P columnDef
>             | ADD_P COLUMN columnDef
>
> The reason this fixes it is that now the parser does not have to make
> a shift-reduce decision while EXCLUSION is the next token: it's just
> going to shift all the time, and it only has to reduce once EXCLUSION
> is the current token and it can see the next one as lookahead.  (In
> which case, it will reduce EXCLUSION to ColId and proceed with the
> its-a-ColumnDef path, only if the next token isn't "(" or "USING".)
>
> Another way to think about is is that we are forcing bison to split
> this one state into two, but I find it easier to understand how to
> fix the problem by looking for ways to postpone the reduce decision.
>
>   

This is a pretty good short explanation of how to deal with shift/reduce 
problems in bison. With your permission I'm going to copy it to the Wiki 
- it's amazing given the ubiquity of bison, yacc and friends how little 
the mechanics of LALR(1) parsers are understood. We've had many people 
puzzling over it over the years.

cheers

andrew