On Mon, 8 Sep 2003, Tom Lane wrote:
> "scott.marlowe" <scott.marlowe@ihs.com> 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.
