Re: [HACKERS] FOREIGN KEY and shift/reduce

> > 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.
> 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.

I'd like a chance to fix it at the grammar level. It involves mixing
NOT DEFERRABLE and NOT NULL into the same clauses, but if I can work
it out I'd rather isolate the Big Kluges in gram.y, which seems to
collect that kind of stuff. scan.l is still fairly clean...

- Thomas

--
Thomas Lockhart lockhart(at)alumni(dot)caltech(dot)edu
South Pasadena, California