RE: Exploring sequences (sequence context within a transaction)
От | Nicolas Huillard |
---|---|
Тема | RE: Exploring sequences (sequence context within a transaction) |
Дата | |
Msg-id | 01C0F37F.417A3CA0.nhuillard@ghs.fr обсуждение исходный текст |
Ответ на | Exploring sequences (sequence context within a transaction) ("NetBeans" <erik@cariboulake.com>) |
Список | pgsql-general |
curval retreives the current value of the sequence FOR THE CURRENT CLIENT. There is this no concurrency problem : you can call curval on client 1 afeter having generated many values from the sequence, curval will always return the same value for the same client. NH > -----Message d'origine----- > De: NetBeans [SMTP:erik@cariboulake.com] > Date: mardi 5 juin 2001 09:21 > À: pgsql-general@postgresql.org > Objet: [GENERAL] Exploring sequences (sequence context within a transaction) > > I searched through mailing list archives but was unable to find full > coverage of this question -- my apologies if this is a reposted question. > > As in the FAQ, I am trying to retrieve the value of a sequence value from a > newly inserted row. So, first I call something like: > > insert into foobar (foo, bar) values (nextval('foobar_foo_seq'), > 'whatever'); > > Then, I want to retrieve the value that generated from the sequence and > inserted into the table, so I use a call to currval: > > insert into foobar_rel_table(foo_fk, baz) values > (currval('foobar_foo_seq', 'something else'); > > This is (one of the methods that is) prescribed in the FAQ. However, I'm > concerned that another transaction attempting to insert into the same table > might make a call to nextval('foobar_foo_seq') between the two operations > above. This would mean that my second statement would use the wrong value > from the sequence. > I've tested this scenario with different transaction isolation levels, and > it appears that any state changes to sequences become immediately visible to > other transactions (obviously, a read-commited type strategy wouldn't work, > however, serializing access to sequences, or explicit locking would solve > this problem). > > Has anyone else come across this problem, and is there a workaround? If > not, are there any alternate suggestions for generating a PK on insert and > immediately retrieving it that is free from concurrency issues? > > Any help would be appreciated. Thanks! -- Erik > > -- > Erik Pearson > erik@cariboulake.com > http://www.cariboulake.com > > > > > ---------------------------(end of broadcast)--------------------------- > TIP 3: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to majordomo@postgresql.org so that your > message can get through to the mailing list cleanly >
В списке pgsql-general по дате отправления: