Thread

Re: Fix GUC_NO_SHOW_ALL test scenario in 003_check_guc.pl

Nitin Jadhav <nitinjadhavpostgres@gmail.com> — 2023-02-04T19:26:58Z

> 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 <tgl@sss.pgh.pa.us> wrote:
>
> Nitin Jadhav <nitinjadhavpostgres@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