Re: [BUGS] 'SET LOCAL ROLE blah;' doesn't work?
От | Tom Lane |
---|---|
Тема | Re: [BUGS] 'SET LOCAL ROLE blah;' doesn't work? |
Дата | |
Msg-id | 24895.1189353275@sss.pgh.pa.us обсуждение исходный текст |
Список | pgsql-hackers |
[ 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
В списке pgsql-hackers по дате отправления: