Обсуждение: gram.y foreign keys

OK, I've put in fixes to get Jan up and running on column foreign
keys. The current fix forces NOT NULL arguments to be near the
beginning of a column constraint list, and enforces the SQL92
requirement that the DEFAULT clause occur nearly first in a column
constraint.

As Jan probably already knows, the shift/reduce conflicts all happened
as a result of NOT NULL and NOT DEFERRABLE clauses; removing either
eliminated the conflicts.

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.

I'm leaving town through next weekend (back the 28th) and can pick
this up for more work then.

btw, regression tests pass except for the rules test with known
formatting differences.
                  - Thomas

-- 
Thomas Lockhart                lockhart@alumni.caltech.edu
South Pasadena, California

Let me know if you want to discussed this over the phone for ideas.


> OK, I've put in fixes to get Jan up and running on column foreign
> keys. The current fix forces NOT NULL arguments to be near the
> beginning of a column constraint list, and enforces the SQL92
> requirement that the DEFAULT clause occur nearly first in a column
> constraint.
> 
> As Jan probably already knows, the shift/reduce conflicts all happened
> as a result of NOT NULL and NOT DEFERRABLE clauses; removing either
> eliminated the conflicts.
> 
> 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.
> 
> I'm leaving town through next weekend (back the 28th) and can pick
> this up for more work then.
> 
> btw, regression tests pass except for the rules test with known
> formatting differences.
> 
>                    - Thomas
> 
> -- 
> Thomas Lockhart                lockhart@alumni.caltech.edu
> South Pasadena, California
> 
> ************
> 


--  Bruce Momjian                        |  http://www.op.net/~candle pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026
 

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