> 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