[ see thread at
http://archives.postgresql.org/pgsql-bugs/2007-06/msg00166.php ]
Stephen Frost <sfrost@snowman.net> writes:
> * Alvaro Herrera (alvherre@commandprompt.com) wrote:
>> Tom Lane wrote:
>>> So actually, ON_ERROR_ROLLBACK breaks *any* use of SET LOCAL, not just
>>> ROLE. Not sure that this is fixable :-(
>>
>> Maybe if psql sees "SET LOCAL" it shouldn't send the RELEASE command.
>> But it seems a bit error prone to be finding each command that may be
>> affected by RELEASE ... what other thing do we have that works at the
>> level of subtransactions?
> At the very least, anything which does work at the subtransaction level
> and not the transaction level should be documented as such... I don't
> see anything (perhaps I've missed it) in the 'set local' or the 'release
> savepoint' documentation which describes this behavior... :/
I came across this open issue by chance while looking through my mail
folder, and realized that the recently proposed change to SET LOCAL's
behavior would resolve Stephen's complaint. I believe that the end
result of the discussion in this thread:
http://archives.postgresql.org/pgsql-hackers/2007-09/msg00030.php
was that we should make SET LOCAL's effects persist until the end of
the current top transaction, unless reverted by subtransaction rollback
or the save/restore action of a function-local SET option for the same
GUC variable. With that change, psql's automatic RELEASEs for
ON_ERROR_ROLLBACK mode won't affect the state of GUC variables.
So this reinforces my feeling that we came to the right conclusion
in last week's thread. I haven't done anything about revising
the GUC code for that, but will get on it now.
regards, tom lane
