> I think it's poor practice to try to enforce such a restriction via
> the grammar, because that way you cannot generate an error more
> specific than "parse error near FOO". It'd be better to allow the
> same ColQualifier for SERIAL as for any other column type, and then to
> put sanity checks in analyze.c that would complain about conflicting
> specifications. We have, or should have, most of those checks in
> place already to catch conflicting ColQualifier entries for a plain
> column type (eg, "foo int4 NULL NOT NULL"). Also, I do not like
> generating hard errors for specifications that are merely redundant
> ("foo SERIAL NOT NULL"); is there any basis in the SQL spec for
> refusing such constructs?
Basis? Basis?? Since SERIAL is an extension, there is not anything
defined explicitly. And SQL tends to be a context-sensitive language
(hmm, what's the term for that?) so it does things in different ways
all over the place; it's not very self-consistant. What *should*
happen with a declaration like "foo int NOT NULL NOT NULL"? One could
argue that the backend should just do it, or perhaps should reject
this as a possibly corrupted declaration.
When I first implemented SERIAL, I'm pretty sure I would have had
trouble checking for conflicting qualifiers. But maybe now all the
pieces are there to do it right. Will look at it...
Anyway, I agree with your points, and will put this on my ToDo. btw, I
still have an item about the parser swallowing multiple SERIAL or
PRIMARY KEY declarations (don't remember which right now); will get to
that also.
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
