Horton
Menu

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

Jonathan S. Katz <jkatz@postgresql.org>

View thread
From: "Jonathan S. Katz" <jkatz@postgresql.org>
To: Mark Dilger <mark.dilger@enterprisedb.com>, Tom Lane <tgl@sss.pgh.pa.us>
Cc: Andrew Dunstan <andrew@dunslane.net>, David Rowley <dgrowleyml@gmail.com>, Joe Conway <mail@joeconway.com>, Alvaro Herrera <alvherre@alvh.no-ip.org>, PostgreSQL Developers <pgsql-hackers@lists.postgresql.org>
Date: 2022-04-07T16:49:34Z
Lists: pgsql-hackers 
On 4/7/22 12:42 PM, Mark Dilger wrote:
> 
> 
>> On Apr 7, 2022, at 9:37 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>
>> Maybe I'm atypical, but I'm probably going to use tab completion
>> either way, so it's not really more keystrokes.
> 
> Same here, because after tab-completing \dcon\t\t into \dconfig, I'm likely to also tab-complete to get the list of parameters.  I frequently can't recall the exact spelling of them.

This seems like the only "\d" command that would require tab completion, 
given all the others are far less descriptive (\dt, \dv, etc.) And at 
least from my user perspective, if I ever need anything other than \dt, 
I typically have to go to \? to look it up.

I'm generally in favor of consistency, though in case skewing towards 
what we expose to the user. If "\dconfig" gives a bit more across the 
board, I'm OK with that. "\dparam" could be a bit confusing to end users 
("parameter for what?") so I'm -1 on that.

Jonathan

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Be more careful about GucSource for internally-driven GUC settings.

  2. Fix case sensitivity in psql's tab completion for GUC names.

  3. Further tweak the default behavior of psql's \dconfig.

  4. Tweak the default behavior of psql's \dconfig.

  5. psql: add \dconfig command to show server's configuration parameters.

  6. Allow granting SET and ALTER SYSTEM privileges on GUC parameters.