Re: [HACKERS] PoC plpgsql - possibility to force custom or generic plan

Поиск
Список
Период
Сортировка
От Greg Stark
Тема Re: [HACKERS] PoC plpgsql - possibility to force custom or generic plan
Дата
Msg-id CAM-w4HM=ydO4vuT-ZkAPT5uXNKs4w089djXxmoEbHc+GSz2KtA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] PoC plpgsql - possibility to force custom or genericplan  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
Ответы Re: [HACKERS] PoC plpgsql - possibility to force custom or generic plan  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
Список pgsql-hackers
On 25 January 2017 at 20:06, Jim Nasby <Jim.Nasby@bluetreble.com> wrote:
> GUCs support SET LOCAL, but that's not the same as local scoping because the
> setting stays in effect unless the substrans aborts. What I'd like is the
> ability to set a GUC in a plpgsql block *and have the setting revert on
> block exit*.

I'm wondering which GUCs you have in mind to use this with.

Because what you're describing is dynamic scoping and I'm wondering if
what you're really looking for is lexical scoping. That would be more
in line with how PL/PgSQL variables are scoped and with how #pragmas
usually work. But it would probably not be easy to reconcile with how
GUCs work.

-- 
greg



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Ashutosh Sharma
Дата:
Сообщение: Re: [HACKERS] Microvacuum support for Hash Index
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: [HACKERS] Failure in commit_ts tap tests