Re: Per-function GUC settings: trickier than it looked
| От | Florian G. Pflug |
|---|---|
| Тема | Re: Per-function GUC settings: trickier than it looked |
| Дата | |
| Msg-id | 46DC2A8E.4040505@phlo.org обсуждение исходный текст |
| Ответ на | Re: 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: > "Florian G. Pflug" <fgp@phlo.org> writes: >> Tom Lane wrote: > So it seems that only SET LOCAL within a function with per-function > GUC settings is at issue. I think that there is a pretty strong > use-case for saying that if you have a per-function setting of a > particular variable foo, then any "SET LOCAL foo" within the function > ought to vanish at function end --- for instance a function could want > to try a few different search_path settings and automatically revert to > the caller's setting on exit. Agreed. > The question is what about SET LOCAL > on a variable that *hasn't* been explicitly SET by the function > definition. Either approach we take with it could be surprising, > but probably having it revert at function end is more surprising... At least for me, the least surprising behaviour would be to revert it too. Than the rule becomes "a function is always executed in a pseudo-subtransaction that affects only GUCs" Since at least for pl/pgsql, a function body *alreay* is a BEGIN/END block - and therefore syntactically even looks like a subtransaction - this seems quite logical. And it would mean that the semantics of "SET LOCAL" won't change, just because you add an EXCEPTION clause to the function's toplevel BEGIN/END block. greetings, Florian Pflug
В списке pgsql-hackers по дате отправления: