From: | Thomas Lockhart <lockhart(at)alumni(dot)caltech(dot)edu> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, Don Baccus <dhogaza(at)pacifier(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgreSQL(dot)org> |
Subject: | Re: [HACKERS] Primary key requires SERIAL |
Date: | 1999-11-19 15:32:54 |
Message-ID: | 38356DA6.539BD371@alumni.caltech.edu |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> 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(at)alumni(dot)caltech(dot)edu
South Pasadena, California
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 1999-11-19 15:36:02 | Re: [HACKERS] Curiously confused query parser. |
Previous Message | Thomas Lockhart | 1999-11-19 15:24:52 | Re: [HACKERS] pg_dump bug |