Re: How about a psql backslash command to show GUCs?
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
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-06T21:01:48Z
Lists: pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> 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.
Sure. Nonetheless, having decided to introduce this command, we have
to make that judgement call.
psql-ref.sgml currently explains that
If <replaceable class="parameter">pattern</replaceable> is specified,
only parameters whose names match the pattern are listed. Without
a <replaceable class="parameter">pattern</replaceable>, only
parameters that are set to non-default values are listed.
(Use <literal>\dconfig *</literal> to see all parameters.)
so we have the "all of them" and "ones whose names match a pattern"
cases covered. And the definition of the default behavior as
"only ones that are set to non-default values" seems reasonable enough,
but the question is what counts as a "non-default value", or for that
matter what counts as "setting".
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.
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 →
-
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