Tom Lane Writes: > Michael Fuhr <[EMAIL PROTECTED]> writes: > > On Tue, Feb 01, 2005 at 12:56:20AM -0500, Tom Lane wrote: > >> His point stands though: if you are accessing Postgres > through some > >> kind of connection-pooling software, currval() cannot be trusted > >> across transaction boundaries, since the pool code might give your > >> connection to someone else. In this situation the > >> nextval-before-insert paradigm is the only way. > > > I don't disagree with that; if the thread mentioned > connection pooling > > then I must have overlooked it. > > >> (But in most of the applications I can think of, your uses > of currval > >> subsequent to an INSERT ought to be in the same transaction as the > >> insert, so are perfectly safe. If your connection pooler takes > >> control away from you within a transaction block, you need a less > >> broken > >> pooler...) > > > That's the common situation I was talking about: doing an > INSERT and > > immediately calling currval(), presumably in the same transaction. > > I should have been more clear about that and warned what > could happen > > in other situations. Thanks. > > Apropos to all this: Tatsuo recently proposed a RESET > CONNECTION command that could be used to reset a connection > between pooling assignments, so as to be sure that different > pooled threads wouldn't see state that changes depending on > what some other thread did. It seems like RESET CONNECTION > ought to reset all currval() states to the "error, currval > not called yet" condition. Comments?
I have a suggestion... For libpq: Since OID's are now deprecated, and will eventually disappear, wouldn't it be a good idea, to have INSERT and UPDATE return a copy of the tuple that was inserted/updated? This way, you could have a funtion to fetch an arbitrary named column from that tuple. Like: last_insert_value(tuple,'column_name') ... John ---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]