Re: Extended SERIAL parsing

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Böszörményi Zoltán <zboszor(at)dunaweb(dot)hu>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Extended SERIAL parsing
Date: 2006-06-12 17:55:20
Message-ID: 10941.1150134920@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

=?iso-8859-2?Q?B=F6sz=F6rm=E9nyi_Zolt=E1n?= <zboszor(at)dunaweb(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2006-06-12 17:57:33 Re: CSV mode option for pg_dump
Previous Message Joshua D. Drake 2006-06-12 17:54:11 Re: CSV mode option for pg_dump