Date: Mon, 31 Jan 2022 16:56:45 -0600
From: Justin Pryzby <pryzby@telsasoft.com>
To: Michael Paquier <michael@paquier.xyz>
Cc: Peter Eisentraut <peter.eisentraut@enterprisedb.com>,
	Kyotaro Horiguchi <horikyota.ntt@gmail.com>,
	pgsql-hackers@lists.postgresql.org, bruce@momjian.us,
	tgl@sss.pgh.pa.us
Subject: Re: GUC flags
Message-ID: <20220131225645.GZ23027@telsasoft.com>
References: <20220125010729.GC23027@telsasoft.com>
 <d363c358-2c67-92bc-660f-ff82636c155f@enterprisedb.com>
 <20220125180751.GH23027@telsasoft.com>
 <YfCb03sRzkgNVwbL@paquier.xyz>
 <20220126034426.GN23027@telsasoft.com>
 <YfDqSVZlzdzZO9x6@paquier.xyz>
 <20220128043621.GA23027@telsasoft.com>
 <YfTg/WHNLVVygy8v@paquier.xyz>
 <20220130001849.GR23027@telsasoft.com>
 <Yfdw9WWJ/BMl7QYd@paquier.xyz>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Yfdw9WWJ/BMl7QYd@paquier.xyz>
User-Agent: Mutt/1.9.4 (2018-02-28)
Archived-At: 
 <https://www.postgresql.org/message-id/20220131225645.GZ23027%40telsasoft.com>
Precedence: bulk

On Mon, Jan 31, 2022 at 02:17:41PM +0900, Michael Paquier wrote:
> With all those doc fixes, applied after an extra round of review.  So
> this makes us rather covered with the checks on the flags.

Thanks

> Now, what do we do with the rest of check_guc that involve a direct
> lookup at what's on disk.  We have the following:
> 1) Check the format of the option lists in guc.c.
> 2) Check the format of postgresql.conf.sample:
> -- Valid options preceded by a '#' character.
> -- Valid options followed by ' =', with at least one space before the
> equal sign.
> 3) Check that options not marked as NOT_IN_SAMPLE are in the sample
> file.
> 
> I have never seen 1) as a problem, and pgindent takes care of that at
> some degree.  2) is also mostly cosmetic, and committers are usually
> careful when adding a new GUC.  3) would be the most interesting
> piece, and would cover most cases if we consider that a default
> installation just copies postgresql.conf.sample over, as proposed
> upthread in 0002.
> 
> Now, 3) has also the problem that it would fail installcheck as one
> can freely add a developer option in the configuration.  We could

I'm not clear on what things are required/prohibited to allow/expect
"installcheck" to pass.  It's possible that postgresql.conf doesn't even exist
in the data dir, right ?

It's okay with me if the config_file-reading stuff isn't re-implemented.

-- 
Justin