Sync guc.c and postgresql.conf.sample with the SGML docs.
authorTom Lane <tgl@sss.pgh.pa.us>
Sat, 8 May 2021 16:13:33 +0000 (12:13 -0400)
committerTom Lane <tgl@sss.pgh.pa.us>
Sat, 8 May 2021 16:13:33 +0000 (12:13 -0400)
commita55a98477b690dedb9b4368d7e5710c8e7fa534e
tree5689d774be45d239c546c9dd34e8931b643facab
parentf9b809e7fbe36cd3fe1ce33edb277288a31da386
Sync guc.c and postgresql.conf.sample with the SGML docs.

It seems that various people have moved GUCs around in the config.sgml
listing without bothering to make the code agree.  Ensure that the
config_group codes assigned to GUCs match where they are listed in
config.sgml.  Likewise ensure that postgresql.conf.sample lists GUCs
in the same sub-section and same ordering as they appear in config.sgml.

(I've got some doubts about some of these choices, but for the purposes
of this patch, we'll treat config.sgml as gospel.)

Notably, this requires adding a WAL_RECOVERY config_group value,
because 1d257577e didn't.  As long as we're renumbering that enum
anyway, let's take out the values corresponding to major groups
that are divided into sub-groups.  No GUC should be assigned to the
major group itself, so those values just create a temptation to
do the wrong thing, while adding work for translators.

In passing, adjust the short_desc strings for PRESET_OPTIONS GUCs
to uniformly use the phrasing "Shows XYZ.", removing the impression
some of these strings left that you can set the value.

While some of these errors are old, no back-patch, as changing the
contents of the pg_settings view in stable branches seems more likely
to be seen as a compatibility break than anything helpful.

Bharath Rupireddy, Justin Pryzby, Tom Lane

Discussion: https://postgr.es/m/16997-ff16127f6e0d1390@postgresql.org
Discussion: https://postgr.es/m/20210413123139.GE6091@telsasoft.com
src/backend/utils/misc/guc.c
src/backend/utils/misc/postgresql.conf.sample
src/include/utils/guc_tables.h