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

st 6. 4. 2022 v 19:49 odesílatel Tom Lane <tgl@sss.pgh.pa.us> napsal:
>
> 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?

I like this idea. Also I'm interested in contributing this. Feel free
to ping me if welcomed, I can try to prepare at least the initial
patch. Currently it seems the discussion is related mostly to the
command name, which can be changed at any time.

> 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 >= 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-6BEB63AF3029@enterprisedb.com
>
>