Re: [HACKERS] FOREIGN KEY and shift/reduce

wieck(at)debis(dot)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