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

Robert Haas <robertmhaas@gmail.com>

From: Robert Haas <robertmhaas@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Justin Pryzby <pryzby@telsasoft.com>, "Jonathan S. Katz" <jkatz@postgresql.org>, 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-06T17:02:04Z
Lists: pgsql-hackers
On Mon, Jun 6, 2022 at 12:02 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Thoughts?

This all seems pretty subjective. As someone who sometimes supports
customers, I usually kind of want the customer to give me all the
settings, just in case something that didn't seem important to them
(or to whoever coded up the \dconfig command) turns out to be
relevant. It's easier to ask once and then look for the information
you need than to go back and forth asking for more data, and I don't
want to have to try to infer things based on what version they are
running or how a certain set of binaries was built.

But if I already know that the configuration on a given system is
basically sane, I probably only care about the parameters with
non-default values, and a computed parameter can't be set, so I guess
it has a default value by definition. So if the charter for this
command is to show only non-default GUCs, then it seems reasonable to
leave these out.

I think part of the problem here, though, is that one can imagine a
variety of charters that might be useful. A user could want to see the
parameters that have values in their session that differ from the
system defaults, or parameters that have values which differ from the
compiled-in defaults, or parameters that can be changed without a
restart, or all the pre-computed parameters, or all the parameters
that contain "vacuum" in the name, or all the query-planner-related
parameters, or all the parameters on which any privileges have been
granted. And it's just a judgement call which of those things we ought
to try to accommodate in the psql syntax and which ones ought to be
done by writing an ad-hoc query against pg_settings.

-- 
Robert Haas
EDB: http://www.enterprisedb.com



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.