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