Tom Lane wrote:
> So I coded up a patch for this, based on the idea of creating a
> quasi-subtransaction that affects only GUC while entering/exiting a
> function that has GUC settings attached. The specified settings are
> applied as if by SET LOCAL before starting function execution, and then
> they drop out during "subtransaction" exit. (I'll post the code to
> pgsql-patches in a moment.)
>
> But on reflection I realize that there are some interesting properties
> to this approach:
>
> * if you do "SET LOCAL foo" when you are in a function that has a
> "SET foo" property, the setting disappears at function exit. But if
> you do "SET foo" it persists. This might be OK, but it seems a bit odd.
That seems OK - the same happens inside a BEGIN/EXCEPTION/END block, no?
> * in fact, if you do "SET LOCAL foo" when you are in a function that has
> any "SET" property at all, the setting disappears at function exit,
> whether foo was one of the variables SET by the function definition or
> not.
Hm... That is a bit surprising... Maybe all functions should create a
such GUC-only substransaction-like thing. That might create problems
for inlining - but only if you can actually change GUCs from plsql
function, which maybe you cant...
> We could perhaps get away with defining that as being the behavior,
> but it doubtless will surprise someone sometime. What *should* these
> interactions be like, and has anyone got an idea how to implement their
> suggestion?
What will happen if you have two functions, foo and bar, were the search-path
is overridden for foo, and foo calls bar. I guess bar would be executed with
foo's overridden searchpath. Thats seems a bit surprising - I'd make more
sense to me if bar would use the session's search-path, but that seems hard
to do... Especially because bar *should* use foo's searchpath if foo contained
an explicit "SET LOCAL search_path"
Or maybe I'm just crazy, and the current behavior is fine....
greetings, Florian Pflug
