Thread: How about a psql backslash command to show GUCs?
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 >= 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
On Wed, 6 Apr 2022 at 13:50, Tom Lane <tgl@sss.pgh.pa.us> wrote: > > 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. I may be suffering from some form of the Mandela Effect but I have a distinct memory that once upon a time SHOW actually took patterns like \d does. I keep trying it, forgetting that it doesn't actually work. I'm guessing my brain is generalizing and assuming SHOW fits into the same pattern as \d commands and just keeps doing it even after I've learned repeatedly that it doesn't work. Personally I would like to just make the world match the way my brain thinks it is and make this just work: SHOW enable_* I don't see any value in allowing * or ? in GUC names so I don't even see a downside to this. It would be way easier to discover than another \ command -- greg
On 06.04.2022 20:48, Tom Lane wrote: > However, I very often > find myself resorting to the much more tedious > > select * from pg_settings where name like '%foo%'; > 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* +1, great idea. Right now I use the psql :show variable in my .psqlrc for this purpose: =# \echo :show SELECT name, current_setting(name) AS value, context FROM pg_settings\g (format=wrapped columns=100) | grep =# :show autovacuum autovacuum | on | sighup autovacuum_analyze_scale_factor | 0.1 | sighup autovacuum_analyze_threshold | 50 | sighup autovacuum_freeze_max_age | 200000000 | postmaster autovacuum_max_workers | 3 | postmaster autovacuum_multixact_freeze_max_age | 400000000 | postmaster autovacuum_naptime | 1min | sighup autovacuum_vacuum_cost_delay | 2ms | sighup autovacuum_vacuum_cost_limit | -1 | sighup autovacuum_vacuum_scale_factor | 0.2 | sighup autovacuum_vacuum_threshold | 50 | sighup autovacuum_work_mem | -1 | sighup log_autovacuum_min_duration | -1 | sighup As for the name, I can't think of a better candidate. Any of the previously suggested list of \dconf, \dguc, \dG, \dcp is fine. -- Pavel Luzanov Postgres Professional: https://postgrespro.com The Russian Postgres Company
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 > >