Horton
Menu

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

Tom Lane <tgl@sss.pgh.pa.us>

View thread
From: Tom Lane <tgl@sss.pgh.pa.us>
To: "Jonathan S. Katz" <jkatz@postgresql.org>
Cc: 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 Developers <pgsql-hackers@lists.postgresql.org>
Date: 2022-04-09T16:27:12Z
Lists: pgsql-hackers 
"Jonathan S. Katz" <jkatz@postgresql.org> writes:
> -1, at least for the moment. Sometimes a user doesn't know what they're 
> looking for coupled with being unaware of what the default value is. If 
> a setting is set to a default value and that value is the problematic 
> setting, a user should be able to see that even in a full list.

Sure, but then you do "\dconfig *".  With there being several hundred
GUCs (and no doubt more coming), I'm not sure that "show me every GUC"
is a common use-case at all, let alone so common as to deserve being
the default behavior.

One thing we could perhaps do to reduce confusion is to change the
table heading when doing this, say from "List of configuration parameters"
to "List of non-default configuration parameters".

			regards, tom lane

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.