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  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: KaiGai Kohei
Дата:
Сообщение: [ANN] SE-PostgreSQL 8.2.4-1.0 Released
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Per-function GUC settings: trickier than it looked