On 9/5/07, Michael Paesold <[EMAIL PROTECTED]> 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-local SET, 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 ---------------------------(end of broadcast)--------------------------- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq