Re: [HACKERS] FOREIGN KEY and shift/reduce

Thomas Lockhart <lockhart@alumni.caltech.edu> writes:
>> 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...

Bruce and I were talking about that last night.  I think it could be
fixed by having the grammar treatNOT DEFERRABLEDEFERRABLEINITIALLY IMMEDIATEINITIALLY DEFERRED
as independent ColConstraintElem clauses, and then have a post-pass in
analyze.c that folds the flags into the preceding REFERENCES clause
(and complains if they don't appear right after a REFERENCES clause).
Pretty grotty, especially since you probably wouldn't want to do the
same thing for the other uses of these clauses in TableConstraint
and CreateTrigStmt ... but possibly cleaner than a lexer hack.

Another possible approach is to leave scan.l untouched and put a filter
subroutine between gram.y and scan.l.  The filter would normally just
call the scanner and return the token as-is; but when it gets a NOT
token, it would call the scanner again to see if it gets a NULL token.
If so, it returns a single "NOTNULL" token to the grammar; otherwise
it stashes away the lookahead token to return on the next call.

This last approach probably involves the least amount of dirt, but
it does require being able to get in between yacc and lex.  I'm not
sure whether we'd have portability problems doing that; never tried it.
        regards, tom lane