Re: [HACKERS] gram.y foreign keys

Thomas Lockhart <lockhart(at)alumni(dot)caltech(dot)edu> writes:
> I poked at it for *hours*, and have not yet stumbled on the correct
> layout to give full flexibility while allowing the new constraint
> attributes. Jan was thinking that he needed some token lookahead to do
> this, but I'll be suprised if that is required to solve this for the
> SQL92 case: it would be the first and only instance of syntax which
> can not be solved by our yacc parser and istm that the spec would try
> to stay away from that. The successful technique for fixing this will
> likely involve unrolling more clauses to allow yacc to juggle more
> clauses simultaneously before forcing a shift/reduce operation.

The argument for adding a token lookahead wasn't that it is impossible
to do it at the grammar level; it was that it looked a lot simpler,
more understandable, and more robust/maintainable to do it as a token
filter than by grammar-unrolling.

If you've spent hours on it and can't find any better solution than
restricting the order of column constraint clauses, I'd say that kind
of proves the point, no?

The other way we had discussed of attacking it was to postpone some
processing to analyze.c (see thread around 10-Dec).

Anyway, IMNSHO we can't release with an artificial restriction on
column constraint clause order; it's way too likely to break existing
code, even if it is within the letter of the SQL spec. This'll do for
beta testing but we need something better before 7.0 release.

regards, tom lane