Re: Per-function GUC settings: trickier than it looked
От | Brendan Jurd |
---|---|
Тема | Re: Per-function GUC settings: trickier than it looked |
Дата | |
Msg-id | 37ed240d0709041311i6d84e8fdg9847fa4b4b5391d1@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Per-function GUC settings: trickier than it looked (Michael Paesold <mpaesold@gmx.at>) |
Ответы |
Re: Per-function GUC settings: trickier than it looked
|
Список | pgsql-hackers |
On 9/5/07, Michael Paesold <mpaesold@gmx.at> wrote: > Tom Lane wrote: > > Basically my perspective on SET LOCAL is that its current behavior is a > > bug, and even though it's been that way for a couple major releases now, > > it's still something we oughta fix while we are busy whacking that part > > of the code around. Florian's example with SET TRANSACTION READ ONLY > > proves that it's a bug --- RELEASE is not defined to change any > > transaction modes. > > Yeah, I think your original proposal was really sound. I would not > expect the current SET LOCAL behaviour in the context of savepoints. > If we really need the current behaviour, we should find a new name for > this lasts-until-savepoint-release-or-transaction-end thingy. So, if I read you correctly, in summary we'd like to: * make SET LOCAL local to the transaction (i.e., make it behave as documented),* abandon the idea of a subtransaction-localSET, because the new function-local SET takes care of the interesting use-cases for that,* somehow deal with the incompatibility with the 8.2"security definer" workaround. Tom's proposal to handle the latter was that when a function-local SET reverts, it overrides any inner SET LOCALs. Am I on the right page? Cheers, BJ
В списке pgsql-hackers по дате отправления: