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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Justin Pryzby <pryzby(at)telsasoft(dot)com>, "Jonathan S(dot) Katz" <jkatz(at)postgresql(dot)org>, Julien Rouhaud <rjuju123(at)gmail(dot)com>, Christoph Berg <myon(at)debian(dot)org>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, Joe Conway <mail(at)joeconway(dot)com>, Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, David Rowley <dgrowleyml(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: How about a psql backslash command to show GUCs?
Date: 2022-06-06 21:01:48
Message-ID: 952350.1654549308@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2022-06-06 21:11:19 Re: oat_post_create expected behavior
Previous Message Fabien COELHO 2022-06-06 20:39:17 Re: pgcon unconference / impact of block size on performance