Re: add \dpS to psql
Nathan Bossart <nathandbossart@gmail.com>
From: Nathan Bossart <nathandbossart@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Isaac Morland <isaac.morland@gmail.com>, Justin Pryzby <pryzby@telsasoft.com>, Pavel Luzanov <p.luzanov@postgrespro.ru>, pgsql-hackers@postgresql.org
Date: 2022-12-08T17:15:03Z
Lists: pgsql-hackers
On Thu, Dec 08, 2022 at 12:15:23AM -0500, Tom Lane wrote: > Nathan Bossart <nathandbossart@gmail.com> writes: >> On Wed, Dec 07, 2022 at 11:48:20PM -0500, Isaac Morland wrote: >>> My previous analysis >>> shows that there is no vast hidden demand for new privilege bits. If we >>> implement MAINTAIN to control access to VACUUM, ANALYZE, REFRESH, CLUSTER, >>> and REINDEX, we will cover everything that I can find that has seriously >>> discussed on this list, and still leave 3 unused bits for future expansion. > >> If we added CLUSTER, REFRESH MATERIALIZED VIEW, and REINDEX as individual >> privilege bits, we'd still have 13 remaining for future use. > > I think the appropriate question is not "have we still got bits left?". > It should be more like "under what plausible scenario would it be useful > to grant somebody CLUSTER but not VACUUM privileges on a table?". > > I'm really thinking that MAINTAIN is the right level of granularity > here. Or maybe it's worth segregating exclusive-lock from > not-exclusive-lock maintenance. But I really fail to see how it's > useful to distinguish CLUSTER from REINDEX, say. The main idea behind this work is breaking out privileges into more granular pieces. If I want to create a role that only runs VACUUM on some tables on the weekend, why ѕhould I have to also give it the ability to ANALYZE, REFRESH, CLUSTER, and REINDEX? IMHO we should really let the user decide what set of privileges makes sense for their use-case. I'm unsure the grouping all these privileges together serves much purpose besides preserving ACL bits. The other reason I'm hesitant to group the privileges together is because I suspect it will be difficult to reach agreement on how to do so, as evidenced by past discussion [0]. That being said, I'm open to it if we find a way that folks are happy with. For example, separating exclusive-lock and non-exclusive-lock maintenance actions seems like a reasonable idea (which perhaps is an argument for moving VACUUM FULL out of the VACUUM privilege). [0] https://postgr.es/m/67a1d667e8ec228b5e07f232184c80348c5d93f4.camel%40j-davis.com -- Nathan Bossart Amazon Web Services: https://aws.amazon.com
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Fix psql \?'s entries for \dp and \z.
- dda9f8e7bc2e 16.0 landed
-
psql: Add support for \dpS and \zS.
- d913928c9c5e 16.0 landed
-
Add grantable MAINTAIN privilege and pg_maintain role.
- 60684dd834a2 16.0 landed