On Mon, 8 Sep 2003, Tom Lane wrote: > "scott.marlowe" <[EMAIL PROTECTED]> writes: > > On Mon, 8 Sep 2003, Bruce Momjian wrote: > >> I don't know how you could have an application that doesn't know if it > >> has issued a nextval() in the current connection. Unless you can explain > >> that, we have no intention of playing tricks with currval() for > >> connection pooling. > > > Actually, I would think the very act of using connection pooling would > > ensure that applications may well not know whether or not a nextval had > > been called. > > The point is that it's not very sensible to be using currval except > immediately after a nextval --- usually in the same transaction, I would > think.
I'm pretty sure my second paragraph agreed with you on that. > Certainly, not resetting currval implies that there is > *potential* coupling between different transactions that happen to share > a connection. But ISTM that such coupling would represent a bug in the > application. And that one too. > Chris said he was using currval being undefined to know that no rows > were inserted, but this seems less than compelling to me (why not look > at the results of the insert commands you used?). I'd support adding a > currval-reset feature if someone can make a more compelling argument why > a connection-pooling application would need it. I'd say that if someone is looking at that, it would be better to have some kind of reset_connection call that makes a connection look like you just established it. Bit I'd never use it. ---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
