Re: [HACKERS] Primary key requires SERIAL

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Thomas Lockhart <lockhart(at)alumni(dot)caltech(dot)edu>
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 06:48:03
Message-ID: 1502.942994083@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Thomas Lockhart <lockhart(at)alumni(dot)caltech(dot)edu> writes:
> The grammar allows *only* PRIMARY KEY on the SERIAL column
> declaration, since the other keywords or clauses are either redundant
> or nonsensical in the context of a serial column.

Just to put another item on your todo list ;-) ...

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?

regards, tom lane

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 1999-11-19 07:02:45 Re: [HACKERS] 7.0 status request
Previous Message Thomas Lockhart 1999-11-19 06:35:59 Re: [HACKERS] 7.0 status request