[ see thread at http://archives.postgresql.org/pgsql-bugs/2007-06/msg00166.php ]
Stephen Frost <[EMAIL PROTECTED]> writes: > * Alvaro Herrera ([EMAIL PROTECTED]) 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 ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend
