At Thu, 26 May 2022 08:53:55 +0900, Michael Paquier <mich...@paquier.xyz> wrote in > On Wed, May 25, 2022 at 04:12:07PM +0900, Kyotaro Horiguchi wrote: > > (sigh..) As the result, no need to fix in this area for now, and I > > don't think there's any generic and reliable way to detect > > inconsistencies of guc variable definitions. > > Hmm. Making the automation test painless in terms of maintenance > consists in making it require zero manual filtering in the list of > GUCs involved, while still being useful in what it can detect. The > units involved in a GUC make the checks between postgresql.conf.sample > and pg_settings.boot_value annoying because they would require extra > calculations depending on the unit with a logic maintained in the > test. > > I may be missing something obvious, of course, but it seems to me that > as long as you fetch the values from postgresql.conf.sample and > cross-check them with pg_settings.boot_value for GUCs that do not have > units, the maintenance would be painless, while still being useful (it > would cover the case of enums, for one). The values need to be > lower-cased for consistency, similarly to the GUC names.
Yeah, "boot_val" is appropreate here. And I noticed that pg_settings has the "unit" field. I'll try using them. Thanks for the suggestion! regards. -- Kyotaro Horiguchi NTT Open Source Software Center
