Re: Fix GUC_NO_SHOW_ALL test scenario in 003_check_guc.pl - Mailing list pgsql-hackers

From Justin Pryzby
Subject Re: Fix GUC_NO_SHOW_ALL test scenario in 003_check_guc.pl
Date
Msg-id 20230129164404.GC22427@telsasoft.com
Whole thread Raw
In response to Re: Fix GUC_NO_SHOW_ALL test scenario in 003_check_guc.pl  (Nitin Jadhav <nitinjadhavpostgres@gmail.com>)
Responses Re: Fix GUC_NO_SHOW_ALL test scenario in 003_check_guc.pl
List 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 by date:

Previous
From: vignesh C
Date:
Subject: Re: [Commitfest 2023-01] has started
Next
From: Thomas Munro
Date:
Subject: Re: lockup in parallel hash join on dikkop (freebsd 14.0-current)