On Fri, 2003-01-10 at 22:14, Ashley Cambrell wrote:
> First problem though is that you have to know the sequence name that
> is autogenerated from the serial
... which is not a legitimate problem, IMHO.
> secondly, I thought that sequences worked outside of transactions
They do, but obviously not in the way you think:
client1=> create table test (a serial);
client1=> insert into test default values;
client1=> select currval('test_a_seq'); ===> returns 1
client2=> insert into test default values;
client2=> select currval('test_a_seq'); ===> returns 2
client1=> select currval('test_a_seq'); ===> (still) returns 1
In any case, using OIDs to uniquely identify rows in user tables isn't a
good idea, IMHO:
(a) OIDs on user tables aren't unique, unless you manually create a
unique index
(b) If you create a unique index and the OID counter wraps around,
you're going to be in trouble
(c) OIDs are only 4-byte (and this isn't likely to change anytime soon,
AFAIK), so wraparound isn't out of the question for many installations
> The users who don't know any better and expect that pg_getlastoid
> should return the last oid will have trouble.
I don't see why: for one thing, the OID field is *already* optional (and
the PHP documentation for the function you're referring to mentions this
explicitely). And if they need to use OIDs in their tables, they can (a)
specify WITH OIDS (b) enable the GUC var so that WITH OIDS is the
default.
> There really should be alternative first, like binding variables and
> RETURNING INTO. Is it on the TODO list by any chance?
IIRC, someone (Philip W?) mentioned they might implement something like
this...
Cheers,
Neil
--
Neil Conway <neilc@samurai.com> || PGP Key ID: DB3C29FC