From: | Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: How about a psql backslash command to show GUCs? |
Date: | 2022-04-06 18:01:17 |
Message-ID: | 699B12D0-1272-490A-9F74-2915BB89F946@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> On Apr 6, 2022, at 10:48 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2022-04-06 18:05:40 | Re: SQL/JSON: JSON_TABLE |
Previous Message | Alvaro Herrera | 2022-04-06 17:58:02 | Re: How about a psql backslash command to show GUCs? |