Re: Fix GUC_NO_SHOW_ALL test scenario in 003_check_guc.pl

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Fix GUC_NO_SHOW_ALL test scenario in 003_check_guc.pl
Дата
Msg-id 192638.1675015507@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Fix GUC_NO_SHOW_ALL test scenario in 003_check_guc.pl  (Justin Pryzby <pryzby@telsasoft.com>)
Ответы Re: Fix GUC_NO_SHOW_ALL test scenario in 003_check_guc.pl  (Michael Paquier <michael@paquier.xyz>)
Список pgsql-hackers
Justin Pryzby <pryzby@telsasoft.com> writes:
> SELECT pg_show_all_settings() ought to keep working when called with no
> parameter.  Tom gave me a hint how to do that for system catalogs here:
> https://www.postgresql.org/message-id/17988.1584472261@sss.pgh.pa.us
> In this case, it might be cleaner to add a second entry to pg_proc.dat
> than to add "CREATE OR REPLACE FUNCTION" to system_functions.sql (I
> tried but couldn't get that to work just now).

I kind of think this is a lot of unnecessary work.  The case that is
problematic is a GUC that's marked GUC_NO_SHOW_ALL but not marked
GUC_NOT_IN_SAMPLE.  There aren't any of those, and I don't think there
are likely to be any in future, because it doesn't make a lot of sense.
Why don't we just make a policy against doing that, and enforce it
with an assertion somewhere in GUC initialization?

            regards, tom lane



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

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: lockup in parallel hash join on dikkop (freebsd 14.0-current)
Следующее
От: Tomas Vondra
Дата:
Сообщение: Re: lockup in parallel hash join on dikkop (freebsd 14.0-current)