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 →
-
Be more careful about GucSource for internally-driven GUC settings.
- 7ab5b4eb4834 15.0 landed
-
Fix case sensitivity in psql's tab completion for GUC names.
- b5607b0746f4 15.0 landed
-
Further tweak the default behavior of psql's \dconfig.
- 139d46ee26a2 15.0 landed
-
Tweak the default behavior of psql's \dconfig.
- 5e70d8b5d18b 15.0 landed
-
psql: add \dconfig command to show server's configuration parameters.
- 3e707fbb4009 15.0 landed
-
Allow granting SET and ALTER SYSTEM privileges on GUC parameters.
- a0ffa885e478 15.0 cited