Re: Per-function GUC settings: trickier than it looked
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: "Florian G. Pflug" <fgp@phlo.org>
Cc: pgsql-hackers@postgresql.org
Date: 2007-09-04T01:02:07Z
Lists: pgsql-hackers
"Florian G. Pflug" <fgp@phlo.org> writes: > It still seems a bit strange that "SET LOCAL" is undone at function-exit, > if the function has a matching SET-clause. But we need that for backwards- > compatibility of the secure-search_path workaround, right? Yeah, I'm afraid we backed ourselves into a corner on that one. > So, to reiterate, my idea is > .) Make "SET TRANSACTION" a synonym for "SET LOCAL" at the SQL-Level. > .) In pl/pgsql, "SET TRANSACTION" sets a new value that is kept after the > function exits, even if the function has a matching SET-clause. > .) "SET LOCAL" in pl/pgsql set a new value that is kept if the function > has no matching SET-clause. If it has one, the value is restored. > In any case, we emit a warning that "SET LOCAL" is going away. > .) One day, make "SET LOCAL" in pl/pgsql mean "local to the surrounding > BEGIN/END block". Independent of any SET-clauses the function > might or might not have. I don't think it's a good idea to change SET LOCAL now and plan on changing it again later ;-). If we really want BEGIN-block-local SET capability, I'd prefer to think of some new keyword for that. But I'm not convinced it's interesting --- given the proposed behavior of function SET-clauses, attaching a SET to your function seems like it'll cover the need for restoring outer values. regards, tom lane