Re: let's make the list of reportable GUCs configurable (was Re: Add%r substitution for psql prompts to show recovery status)

Поиск
Список
Период
Сортировка
От Dave Cramer
Тема Re: let's make the list of reportable GUCs configurable (was Re: Add%r substitution for psql prompts to show recovery status)
Дата
Msg-id CADK3HHJVh+JkVzdpu301OytD1-5haR=CSaQrPHdSRsuERXn2jA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: let's make the list of reportable GUCs configurable (was Re: Add%r substitution for psql prompts to show recovery status)  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers


On Thu, 11 Jul 2019 at 10:19, Robert Haas <robertmhaas@gmail.com> wrote:
On Thu, Jul 11, 2019 at 10:11 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
> > 3. I'm not sure that just ignoring any GUCs we don't find is the right
> > thing.  I'm also not sure that it's the wrong thing, but it might be.
> > My question is: what if there's an extension-owned GUC in play? The
> > library probably isn't even loaded at this stage, unless it's in
> > shared_preload_libraries.
>
> Gut reaction is that define_custom_variable would need to consult
> the list to see if a newly-defined variable should be marked GUC_REPORT.

This suggests creating a list in guc.c instead. I'm unclear as to the visibility of variables in there
How do I make this list visible only to the session ?




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

Предыдущее
От: Andrew Dunstan
Дата:
Сообщение: Re: pgbench - add option to show actual builtin script code
Следующее
От: Alexander Korotkov
Дата:
Сообщение: Re: Add missing operator <->(box, point)