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

Tom Lane wrote:
> "Florian G. Pflug" <fgp(at)phlo(dot)org> writes:
>> Tom Lane wrote:
> So it seems that only SET LOCAL within a function with per-function
> GUC settings is at issue. I think that there is a pretty strong
> use-case for saying that if you have a per-function setting of a
> particular variable foo, then any "SET LOCAL foo" within the function
> ought to vanish at function end --- for instance a function could want
> to try a few different search_path settings and automatically revert to
> the caller's setting on exit.
Agreed.

> The question is what about SET LOCAL
> on a variable that *hasn't* been explicitly SET by the function
> definition. Either approach we take with it could be surprising,
> but probably having it revert at function end is more surprising...

At least for me, the least surprising behaviour would be to
revert it too. Than the rule becomes "a function is always
executed in a pseudo-subtransaction that affects only GUCs"

Since at least for pl/pgsql, a function body *alreay* is a
BEGIN/END block - and therefore syntactically even looks
like a subtransaction - this seems quite logical.

And it would mean that the semantics of "SET LOCAL" won't change,
just because you add an EXCEPTION clause to the function's toplevel
BEGIN/END block.

greetings, Florian Pflug