Re: Per-function GUC settings: trickier than it looked

On 9/5/07, Michael Paesold <mpaesold(at)gmx(dot)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-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