On Sat, May 8, 2021 at 9:55 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > It looks like we are using GUC_NO_SHOW_ALL for unused, deprecated, or
> > the GUCs being used by other commands. Since the above 3 GUCs are
> > being used by START TRANSACTION ISOLATION LEVEL command, it makes
> > sense to make them GUC_NO_SHOW_ALL, but let's keep them under
> > CLIENT_CONN_STATEMENT.
>
> I think that GUCs that aren't listed in config.sgml need to be
> UNGROUPED; it's just confusing to show them as part of a group
> when they're not in that group according to the docs. Also,
> it's almost true that presence of GUC_NO_SHOW_ALL correlates
> exactly with being UNGROUPED. The couple of exceptions are
> legacy entries that perhaps should have been changed when they
> were de-documented.
I think the GUCs that have the GUC_NO_SHOW_ALL flag in guc.c, are not
showing up in pg_settings output along with show all and they are also
not mentioned in the config.sgml. Even if they aren't categorized
under UNGROUPED in guc.c that's not visible to the users. Therefore,
IMO we can retain the transaction_deferrable, transaction_isolation,
transaction_read_only category as is i.e. CLIENT_CONN_STATEMENT, just
add GUC_NO_SHOW_ALL flag and maybe a comment "/* Not for general use
--- used by START TRANSACTION ISOLATION LEVEL */.
> >> * The code's names for the categories do not match up all that
> >> well with the section headings in config.sgml, eg we have
> >> Query Tuning in guc.c and Query Planning in the docs. Should we
> >> try to sync that?
>
> > I think we can change the docs to match the guc.c code wordings. Thoughts?
>
> Meh... not sure why we'd take the docs as gospel up to this point
> and then suddenly reverse course.
>
> After thinking about it, I think it's fine if the guc.c string is a
> shortened form of the config.sgml section title. For instance,
> I don't feel a need to make "Reporting and Logging" match the docs'
> "Error Reporting and Logging". But places where it's just randomly
> different, like "Query Tuning" vs. "Query Planning", probably
> should be fixed to avoid confusion.
+1 to change Query Planning in docs to Query Tuning to match in guc.c.
Remaining seems fine: (in guc.c, in docs) --> (Resource Usage,
Resource Consumption), (Write-Ahead Log, Write Ahead Log), (Query
Tuning, Query Planning), (Reporting and Logging, Error Reporting and
Logging), (Statistics, Run-time Statistics), (Autovacuum, Automatic
Vacuuming)
With Regards,
Bharath Rupireddy.
EnterpriseDB: http://www.enterprisedb.com