Bruce Momjian <[EMAIL PROTECTED]> writes:
> I think we have only a few options:
You forgot
o Do nothing.
IMHO the current behavior is not broken, and does not need fixed.
All of the options you suggest are surely more broken than the current
behavior.
> o Issue a RESET on transaction completion (commit or abort) for any
> SET variable set in the transaction. (This will cause problems
> for API's like ecpg which are always in a transaction.)
RESET would certainly not be a desirable behavior. If we want SET vars
to roll back on abort, then they should roll back --- ie, resume their
transaction-start-time values. But I doubt it's worth the trouble.
That behavior would do nothing to help JDBC implement timeouts, since
they'd still need to change the value again explicitly after successful
transaction completion.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
