Horton
Menu

Re: How about a psql backslash command to show GUCs?

Jonathan S. Katz <jkatz@postgresql.org>

View thread
From: "Jonathan S. Katz" <jkatz@postgresql.org>
To: Robert Haas <robertmhaas@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>
Cc: Justin Pryzby <pryzby@telsasoft.com>, Julien Rouhaud <rjuju123@gmail.com>, Christoph Berg <myon@debian.org>, Pavel Stehule <pavel.stehule@gmail.com>, "David G. Johnston" <david.g.johnston@gmail.com>, Joe Conway <mail@joeconway.com>, Mark Dilger <mark.dilger@enterprisedb.com>, Andrew Dunstan <andrew@dunslane.net>, David Rowley <dgrowleyml@gmail.com>, Alvaro Herrera <alvherre@alvh.no-ip.org>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2022-06-07T14:52:38Z
Lists: pgsql-hackers 
On 6/7/22 10:26 AM, Robert Haas wrote:
> On Mon, Jun 6, 2022 at 5:02 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> I think a reasonable case can be made for excluding "internal" GUCs
>> on the grounds that (a) they cannot be set, and therefore (b) whatever
>> value they have might as well be considered the default.
> 
> I agree.

I think some of these could be interesting if they deviate from the 
default (e.g. "in_hot_standby") as it will give the user context on the 
current state of the system.

However, something like that is still fairly easy to determine (e.g. 
`pg_catalog.pg_is_in_recovery()`). And looking through the settings 
marked "internal" showing the non-defaults may not provide much 
additional context to a user.

+1 for excluding them.

Jonathan

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Be more careful about GucSource for internally-driven GUC settings.

  2. Fix case sensitivity in psql's tab completion for GUC names.

  3. Further tweak the default behavior of psql's \dconfig.

  4. Tweak the default behavior of psql's \dconfig.

  5. psql: add \dconfig command to show server's configuration parameters.

  6. Allow granting SET and ALTER SYSTEM privileges on GUC parameters.