Thanks for being patient with me. I must have fallen on my head
yesterday or something. I *knew* currval and nextval were backend
specific. I got confused because I am working on a middleware layer
with a connection pool that grabs a connection and holds it until the
transaction is finished. Each new transaction might grab a different
backend, but you won't get a new backend until your transaction is
finished.
In other words, in my application the easiest way to insure that
currval and nextval work like they should is to start a transaction
(which grabs a backend connection).
Apparently this has led to some very fuzzy thinking on my part. My
apologies for sending contradictory and confusing posts to the list,
and thanks for clearing that up.
Jason
"Ross J. Reedstrom" <reedstrm@rice.edu> writes:
> Let me say this again, since my previous post is probably unclear:
>
> The code below is safe, even without a transaction, _if it runs in one,
> unshared connection to the DB_. So the danger is much less than you
> might think. Adding the transaction is good (though nextval() _does not_
> rollback, BTW: you get holes in the sequence) because it protects your
> data integrity (no orphan parent records if child fails for other reasons)
> and lets any layers in between know that these go together, not because
> it's needed to cover the multiuser case.
>
> Ross
