Re: [HACKERS] FOREIGN KEY and shift/reduce

> wieck@debis.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.
Tom and I talked about moving NOT DEFERED up into the main level with
NOT NULL.

In gram.y, line 949 and line, could there be a test that if the last
List element of $1 is a constraint, and if $2 is NOT DEFERED, we can set
the bit in $1 and just skip adding the defered node?  If not, we can
throw an error.

Also, ColQualList seems very strange.  Why the two actions?  I have
removed it and made ColQualifier work properly.

--  Bruce Momjian                        |  http://www.op.net/~candle maillist@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