From: | Nathan Bossart <nathandbossart(at)gmail(dot)com> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | describe special values in GUC descriptions more consistently |
Date: | 2025-02-07 22:27:23 |
Message-ID: | Z6aIy4aywxUZHAo6@nathan |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
For many GUCs, special values like -1, "", etc. have some sort of special
meaning, such as disabling the feature. While the documentation seems to
be reasonably good about listing special values, the GUC descriptions are
less consistent. Many GUC descriptions don't state the special values at
all, and the ones that do are inconsistent in phrasing and placement (e.g.,
a couple list them in the short description, but most list them in the long
description). I figured I'd try to add some consistency here.
In the attached patch, I've attempted to apply the following proposed rules
to the descriptions of GUCs that accept special values:
* The special values should be listed at the end of the long description.
* Descriptions should use numerals (0) instead of words (zero).
* The special value notes should be consistently worded and as direct as
possible (e.g., "0 disables the timeout.", "An empty string means to use
the system setting.").
There are a few exceptions, such as max_pred_locks_per_relation and
search_path, where the special values are too complicated to include. And
there are cases like unix_socket_directories, listen_addresses,
application_name, and cluster_name, where the meaning of "" is arguably too
obvious to bother including. There's a good chance that I've missed a
couple, too.
Thoughts?
--
nathan
Attachment | Content-Type | Size |
---|---|---|
v1-0001-Describe-special-values-in-GUC-descriptions-more-.patch | text/plain | 24.0 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2025-02-07 22:41:32 | Re: Cross-type index comparison support in contrib/btree_gin |
Previous Message | Melanie Plageman | 2025-02-07 22:14:45 | Re: Adjusting hash join memory limit to handle batch explosion |