| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Nathan Bossart <nathandbossart(at)gmail(dot)com> |
| Cc: | Isaac Morland <isaac(dot)morland(at)gmail(dot)com>, Justin Pryzby <pryzby(at)telsasoft(dot)com>, Pavel Luzanov <p(dot)luzanov(at)postgrespro(dot)ru>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: add \dpS to psql |
| Date: | 2022-12-08 05:15:23 |
| Message-ID: | 45224.1670476523@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Nathan Bossart <nathandbossart(at)gmail(dot)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.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Smith | 2022-12-08 05:20:04 | Re: PGDOCS - Logical replication GUCs - added some xrefs |
| Previous Message | Isaac Morland | 2022-12-08 05:12:05 | Re: add \dpS to psql |