From: | Zoltan Boszormenyi <zboszor(at)dunaweb(dot)hu> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Extended SERIAL parsing |
Date: | 2006-06-12 19:20:50 |
Message-ID: | 448DBE92.50806@dunaweb.hu |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane írta:
> =?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.
>
Do you mean the allowed and denied contexts of the
NEXT VALUE FOR expression in section 6.13?
(As opposed to nextval() which, as being a function
is allowed more broadly.) This part may still be described
with grammar, unless you mean something more suble.
>>> 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.
>
OK, point taken.
Best regards,
Zoltán Böszörményi
From | Date | Subject | |
---|---|---|---|
Next Message | Joshua D. Drake | 2006-06-12 20:14:41 | Re: CSV mode option for pg_dump |
Previous Message | Jim C. Nasby | 2006-06-12 19:06:28 | Re: CSV mode option for pg_dump |