Re: Per-function GUC settings: trickier than it looked - Mailing list pgsql-hackers

From Florian G. Pflug
Subject Re: Per-function GUC settings: trickier than it looked
Date
Msg-id 46DA28F3.6070005@phlo.org
Whole thread Raw
In response to Per-function GUC settings: trickier than it looked  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Per-function GUC settings: trickier than it looked
List pgsql-hackers
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



pgsql-hackers by date:

Previous
From: David Fetter
Date:
Subject: Re: synchronous_commit: Developer's View
Next
From: Tom Lane
Date:
Subject: Re: synchronous_commit: Developer's View