From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Rod Taylor <pg(at)rbt(dot)ca> |
Cc: | PostgreSQL Patches <pgsql-patches(at)postgresql(dot)org> |
Subject: | Re: NEXT VALUE FOR... |
Date: | 2004-05-07 18:38:56 |
Message-ID: | 14790.1083955136@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-patches |
Rod Taylor <pg(at)rbt(dot)ca> writes:
> NEXT VALUE FOR and CURRENT VALUE FOR where CURRENT is an unreserved
> keyword and VALUE is not reserved in any way (ident with comparison to
> "value").
I see one pretty big problem with this: the SQL2003 spec says clearly
that multiple occurrences of NEXT VALUE FOR should all generate the same
value within a particular row. (See, eg, last sentence of 4.21.2 or the
detailed rules in 6.13. The motivation is analogous to the behavior of
current_timestamp I suppose.) I think it's a bad idea to use the spec's
syntax to represent a non-spec-compliant behavior, which is what this
patch would provide, because that would foreclose doing the right thing
later on.
Offhand I see no simple way to do what the spec asks for within Postgres
:-( but that doesn't mean we should ignore the requirement.
> CURRENT VALUE FOR is an extension of the spec.
If it's not required by the spec, why bother? Since currval is
nonstandard anyway it might as well use a less special-purpose,
more extensible syntax. I would still like to do the Oracle-like
nextval(seqname) idea sometime.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Hallgren | 2004-05-07 18:47:32 | Patch for Makefile.shlib |
Previous Message | Hebert, Caroline | 2004-05-07 12:04:50 | Bug PostGreSQL 7.4.2 |