Re: Per-function GUC settings: trickier than it looked
От | Tom Lane |
---|---|
Тема | Re: Per-function GUC settings: trickier than it looked |
Дата | |
Msg-id | 6345.1188867727@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Per-function GUC settings: trickier than it looked ("Florian G. Pflug" <fgp@phlo.org>) |
Ответы |
Re: Per-function GUC settings: trickier than it looked
|
Список | 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
В списке pgsql-hackers по дате отправления: