Horton
Menu

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

David G. Johnston <david.g.johnston@gmail.com>

View thread
From: "David G. Johnston" <david.g.johnston@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: "Jonathan S. Katz" <jkatz@postgresql.org>, Joe Conway <mail@joeconway.com>, Alvaro Herrera <alvherre@alvh.no-ip.org>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Mark Dilger <mark.dilger@enterprisedb.com>
Date: 2022-04-07T15:10:14Z
Lists: pgsql-hackers 
On Thu, Apr 7, 2022 at 7:56 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:

> "Jonathan S. Katz" <jkatz@postgresql.org> writes:
>
>
> Maybe to appeal to all crowds, we say "list configuration parameters
> > (GUCs)"?
>
> I'm in the camp that says that GUC is not an acronym we wish to expose
> to end users.
>
>
I am too.  In any case, either go all-in with GUC (i.e., \dG or \dguc) or
pretend it doesn't exist - an in-between position is unappealing.

David J.

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.