Re: [HACKERS] FOREIGN KEY and shift/reduce

wieck@debis.com (Jan Wieck) writes:
>     If I allow the <constraint attributes> in column constraints,
>     I  get  2 shift/reduce conflicts. Seems the syntax interferes
>     with NOT NULL.  Actually I commented that part  out,  so  the
>     complete  syntax is available only for table constraints, not
>     on the column level.

>     Could some yacc-guru please take a look at it?

Well, I'm not a guru, but I looked anyway.  It's a mess.  The problem
is that when NOT is the next token, the grammar doesn't know whether
the NOT is starting NOT NULL, which would be a new ColConstraintElem,
or starting NOT DEFERRABLE, which would be part of the current
ColConstraintElem.  So it can't decide whether it's time to reduce
the current stack contents to a finished ColConstraintElem or not.
The only way to do that is to look ahead further than the NOT.

In short, we no longer have an LR(1) grammar.  Yipes.

After a few minutes' thought, it seems that the least unclean way
to attack this problem is to hack up the lexer so that
"NOT<whitespace>NULL" is lexed as a single keyword.  Assuming that
that's doable (I haven't tried, but I think it's possible), the
required changes in the grammar would be small.  The shift/reduce
problem would go away, since we'd essentially have pushed the
required lookahead into the lexer.

It's possible that making this change would even allow us to use
full a_expr rather than b_expr in DEFAULT expressions.  I'm not
sure about it, but that'd be a nice side benefit if so.

Does anyone see a better answer?  This'd definitely be a Big Kluge
from the lexer's point of view, but I don't see an answer at the
grammar level.

BTW --- if we do this, it'd be a simple matter to allow "NOTNULL"
with no embedded space, which is something that I think a number
of other DBMSes accept.  (Which may tell us something about how
they solved this problem...)  It's not a keyword according to 
SQL92, so I'm inclined *not* to accept it, but perhaps someone
else wants to argue the case.
        regards, tom lane