Horton
Menu

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

Mark Dilger <mark.dilger@enterprisedb.com>

View thread
From: Mark Dilger <mark.dilger@enterprisedb.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-hackers@lists.postgresql.org
Date: 2022-04-06T18:01:17Z
Lists: pgsql-hackers 

> On Apr 6, 2022, at 10:48 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 
> So does anyone else like this idea?

Privileges on targets other than parameters have a \d command to show the privileges, as listed in doc/src/sgml/ddl.sgml.  There isn't an obvious reason for omitting parameters from the list so covered.

One of the ideas that got punted in the recent commit was to make it possible to revoke SET on a USERSET guc.  For example, it might be nice to REVOKE SET ON PARAMETER work_mem FROM PUBLIC.  That can't be done now, but for some select parameters, we might implement that in the future by promoting them to SUSET with a default GRANT SET...TO PUBLIC.  When connecting to databases of different postgres versions (albeit only those version 15 and above), it'd be nice to quickly see what context (USERSET vs. SUSET) is assigned to the parameter, and whether the GRANT has been revoked.

So yes, +1 from me.
 
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

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.