On 2025-Oct-13, John Naylor wrote:
> On Fri, Oct 3, 2025 at 1:55 PM Peter Eisentraut <peter@eisentraut.org> wrote:
> > Additionally, I have sorted guc_parameters.dat alphabetically by name,
> > and have added code to enforce the sort order going forward.
>
> That makes sense by default. Another possibility would be to keep them
> in the same order as postgresql.conf.sample. You mentioned earlier it
> may be possible to generate the latter, although it's not yet clear if
> that could be done easily. If not, then keeping them in sync would be
> extra work.
I agree that keeping the guc_parameters.dat file alphabetically sorted
by default would keep the maintenance cost lowest, because we won't have
to make any subjective decisions for new entries. However, automatically
generating the .sample file sounds impractical, considering the
free-form comments that we currently have there. For instance
#max_prepared_transactions = 0 # zero disables the feature
# (change requires restart)
# Caution: it is not advisable to set max_prepared_transactions nonzero unless
# you actively intend to use prepared transactions.
We'd have to store the comments together in the guc_parameters.dat table
so that the sample file knows where and how to put them, and it would
IMO look worse.
Also, the order of entries in postgresql.conf.sample was at some point
carefully considered. Messing that up (by making the entries match
alphabetical order, even within each section) would also be worse IMO.
So we'd have to add values for the sorting to know where in the file
each section goes, what its opening comment is, and where each entry
goes within each section.
I think instead of that mess, maybe we can simply keep the sample file
as-is, cross-check that a line for each non-hidden GUC variable exists,
and perhaps that the commented-out default value matches the data file.
--
Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/
Al principio era UNIX, y UNIX habló y dijo: "Hello world\n".
No dijo "Hello New Jersey\n", ni "Hello USA\n".
