From: Tom Lane <tgl@sss.pgh.pa.us>
To: pgsql-hackers@lists.postgresql.org
cc: Mark Dilger <mark.dilger@enterprisedb.com>
Subject: How about a psql backslash command to show GUCs?
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <3118454.1649267333.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Wed, 06 Apr 2022 13:48:53 -0400
Message-ID: <3118455.1649267333@sss.pgh.pa.us>
Archived-At: <https://www.postgresql.org/message-id/3118455.1649267333%40sss.pgh.pa.us>
Precedence: bulk

It's not difficult to get psql to show you the current value
of a single GUC --- "SHOW" does that fine, and it has tab
completion support for the GUC name.  However, I very often
find myself resorting to the much more tedious

select * from pg_settings where name like '%foo%';

when I want to see some related parameters, or when I'm a bit
fuzzy on the exact name of the parameter.  Not only is this
a lot of typing, but unless I'm willing to type even more to
avoid using "*", I'll get a wall of mostly unreadable text,
because pg_settings is far too wide and cluttered with
low-grade information.

In the discussion about adding privileges for GUCs [1], there
was a proposal to add a new psql backslash command to show GUCs,
which could reduce this problem to something like

\dcp *foo*

(The version proposed there was not actually useful for this
purpose because it was too narrowly focused on GUCs with
privileges, but that's easily fixed.)

So does anyone else like this idea?

In detail, I'd imagine this command showing the name, setting, unit,
and vartype fields of pg_setting by default, and if you add "+"
then it should add the context field, as well as applicable
privileges when server version >=3D 15.  However, there's plenty
of room for bikeshedding that list of columns, not to mention
the precise name of the command.  (I'm not that thrilled with
"\dcp" myself, as it looks like it might be a sub-form of "\dc".)
So I thought I'd solicit comments before working on a patch
not after.

I view this as being at least in part mop-up for commit a0ffa885e,
especially since a form of this was discussed in that thread.
So I don't think it'd be unreasonable to push into v15, even
though it's surely a new feature.

			regards, tom lane

[1] https://www.postgresql.org/message-id/flat/3D691E20-C1D5-4B80-8BA5-6BE=
B63AF3029@enterprisedb.com