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
