Re: NOT {NULL|DEFERRABLE} (was: bug in 7.0)

wieck@debis.com (Jan Wieck) writes:
>     I  would  be able to undo Thomas' changes to the parser (plus
>     your fix for SEQUENCE) and put our idea  of  token  lookahead
>     into instead. The changes are locally to gram.y, and anything
>     works as expected.

>     It's a kludge too, mucking around with a

>         #define yylex() pg_yylex()

>     at the  beginning,  then  later  #undef'ining  it  again  and
>     creating  a  function pg_yylex() that calls the real yylex().
>     Since we insist on bison and ship a gram.c  for  the  others,
>     There can't be any portability problems.

Um.  We do *not* insist on bison, and at least one platform that
I work with would like to keep the option.  Please hold off on this.

The other alternative that was discussed was to put the onus on
analyze.c to fix things up.  Basically, we could make NOT DEFERRABLE
and the other subclauses of foreign key clauses be independent
clauses from the grammar's point of view; that is,
FOREIGN KEY blah blah NOT DEFERRABLE INITIALLY IMMEDIATE

would be parsed as three separate constraint clauses producing three
separate nodes in the column's constraint list.  Then analyze.c would
make a pre-pass over the list to mark the FOREIGN KEY clause with the
right values and remove the extraneous clauses.  (And to complain if
any of them are not in the right place, of course.)

This should get rid of the shift-reduce conflict, because there's
no longer any need to consider shifting in the context of
FOREIGN KEY blah blah . NOT

As far as the grammar is concerned, it can always reduce the FOREIGN
KEY clause at this point; the NOT will introduce a separate clause in
any case, so it doesn't matter whether NULL or DEFERRABLE follows it.

This would be a little bit more work, but it would introduce no
portability risk at all, and in theory it would let us produce better
error messages than the generic "parse error near" message, for at least
some kinds of mistakes.

I don't recall whether Thomas liked that idea either ;-), but I'm coming
around to the opinion that it's the best solution.
        regards, tom lane