Re: Fix GUC_NO_SHOW_ALL test scenario in 003_check_guc.pl

Поиск
Список
Период
Сортировка
От Justin Pryzby
Тема Re: Fix GUC_NO_SHOW_ALL test scenario in 003_check_guc.pl
Дата
Msg-id 20230129164404.GC22427@telsasoft.com
обсуждение исходный текст
Ответ на Re: Fix GUC_NO_SHOW_ALL test scenario in 003_check_guc.pl  (Nitin Jadhav <nitinjadhavpostgres@gmail.com>)
Ответы Re: Fix GUC_NO_SHOW_ALL test scenario in 003_check_guc.pl  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Sun, Jan 29, 2023 at 05:22:13PM +0530, Nitin Jadhav wrote:
> > We could extend pg_show_all_settings() with a boolean parameter to
> > enforce listing all the parameters, even the ones that are marked as
> > NOSHOW, but this does not count on GetConfigOptionValues() that could
> > force a parameter to become noshow on a superuser-only GUC depending
> > on the role that's running the function.  At the end, we'd better rely
> > on a separate superuser-only function to do this job, aka option 1.
> 
> I had started a separate thread [1] to refactor the code around
> GetConfigOptionValues() and the patch is already committed. Now it
> makes our job simpler to extend pg_show_all_settings() with a boolean
> parameter to enforce listing all the parameters, even the ones that
> are marked as NOSHOW. I have attached the patch for the same. Kindly
> look into it and share your thoughts.

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).

-- 
Justin



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

Предыдущее
От: vignesh C
Дата:
Сообщение: Re: [Commitfest 2023-01] has started
Следующее
От: Thomas Munro
Дата:
Сообщение: Re: lockup in parallel hash join on dikkop (freebsd 14.0-current)