On Sat, Jan 14, 2023 at 07:10:55PM +0530, Nitin Jadhav wrote: > Option-1 is, expose a function like pg_settings_get_no_show_all() > which just returns the parameters which are just listed as > GUC_NO_SHOW_ALL (Not in combination with NOT_IN_SAMPLE). We can then > use this function in the test file and verify whether there are config > entries for these. > > Option-2 is, if exposing new function and that too to expose > parameters which are listed as GUC_NO_SHOW_ALL is not recommended, > then how about exposing a function like pg_settings_get_count() which > returns the count of all parameters including GUC_NO_SHOW_ALL. We can > then use this number to verify whether these many are present in the > sample config file. But we cannot show the name of the parameters if > it is not matching. We can just display an error saying "Parameter > with GUC_NO_SHOW_ALL is missing from postgresql.conf.sample".
We would miss the names of the parameters that are marked as NO_SHOW, missing from pg_settings, making debugging harder. > Option-3 is, if exposing both of the above functions is not > recommended, then we can use the existing function > pg_settings_get_flags() for each of the parameters while reading the > sample config file in 003_check_guc.pl. This validates the > GUC_NO_SHOW_ALL parameter if that is present in the sample config > file. It does not validate if it is present in guc.c and missing in > the sample config file. This would make the test more costly by forcing one SQL for each GUC.. > Option-4 is, how about manually adding the parameter name to > 'all_params_array' in 003_check_guc.pl whenever we add such GUCs. > > I am not able to choose any of the above options as each has some > disadvantages but if no other options exist, then I would like to go > with option-3 as it validates more than the one currently doing. > Please share if any other better ideas. 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. How much do we need to care with the duplication this would involve with show_all_settings(), actually? If you don't use the SRF macros, the code would just be a couple of lines with InitMaterializedSRF() doing a loop on GetConfigOptionValues(). Even if that means listing twice the parameters in pg_proc.dat, the chances of adding new parameters in pg_settings is rather low so that would be a one-time change? -- Michael
signature.asc
Description: PGP signature
