Re: Extended SERIAL parsing - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Extended SERIAL parsing
Date
Msg-id 10941.1150134920@sss.pgh.pa.us
Whole thread Raw
In response to Re: Extended SERIAL parsing  (Böszörményi Zoltán <zboszor@dunaweb.hu>)
Responses Re: Extended SERIAL parsing  (Zoltan Boszormenyi <zboszor@dunaweb.hu>)
List pgsql-hackers
Böszörményi Zoltán <zboszor@dunaweb.hu> writes:
> Well, I read all sections of 5WD-02-Foundation-2003-09.pdf
> where "identity" appears, here are the list of changes that will
> be needed for an identity column:

You're missing the hard part: NEXT VALUE FOR is sufficiently different
from nextval() that it will be very painful to implement.  Until we have
a way of doing that, I think it would be unwise to use the SQL syntax
for things that don't behave the way the spec says.  We might find that
spec-compliant sequences need to be a completely different object type,
or something equally evil.  Right now, we have the freedom to do that
if that's what it takes.  With the spec syntax already locked down as
generating PG-style sequences, we'd be hosed.

>> I'm not too happy with converting SERIAL4 and SERIAL8 into reserved
>> words, either, as I believe this patch does.

> Not really, only IDENTITY is added to the list of reserved words,
> serial/serial4/serial8/bigserial are just type names:

You apparently haven't thought very hard about the consequences of what
you did to keywords.c.  But I'll give you a hint: mapping distinct
strings to the same token is a bad idea.
        regards, tom lane


pgsql-hackers by date:

Previous
From: "Joshua D. Drake"
Date:
Subject: Re: CSV mode option for pg_dump
Next
From: Andrew Dunstan
Date:
Subject: Re: CSV mode option for pg_dump