> I don't particularly see why that needs to be the case. Notably, > if we're interested in enforcing a policy even for extension GUCs, > guc.sql can't really do that since who knows whether the extension's > author will bother to run that test with the extension loaded. > On the other hand, moving *all* those checks into guc.c is probably > impractical and certainly will add undesirable startup overhead.
Ok. Understood the other problems. I have attached the v2 patch which uses the idea present in Michael's patch. In addition, I have removed fetching NO_SHOW_ALL parameters while creating tab_settings_flags table in guc.sql and adjusted the test which checks for (NO_RESET_ALL AND NOT NO_SHOW_ALL) as this was misleading the developer who thinks that tab_settings_flags table has NO_SHOW_ALL parameters which is incorrect. Please review and share your thoughts. Thanks & Regards, Nitin Jadhav On Sat, Feb 4, 2023 at 1:07 AM Tom Lane <t...@sss.pgh.pa.us> wrote: > > Nitin Jadhav <nitinjadhavpostg...@gmail.com> writes: > > My concern is if we do this, then we will end up having some policies > > (which can be read from pg_show_all_settings()) in guc.sql and some in > > guc.c. I feel all these should be at one place either at guc.c or > > guc.sql. > > I don't particularly see why that needs to be the case. Notably, > if we're interested in enforcing a policy even for extension GUCs, > guc.sql can't really do that since who knows whether the extension's > author will bother to run that test with the extension loaded. > On the other hand, moving *all* those checks into guc.c is probably > impractical and certainly will add undesirable startup overhead. > > regards, tom lane
v2-0001-Fix-GUC_NO_SHOW_ALL-test-scenarios.patch
Description: Binary data