Nathan Bossart <nathandbossart@gmail.com> writes: > I haven't formed an opinion on whether VACUUM FULL should get its own bit, > but FWIW І just finished writing the first draft of a patch set to add bits > for CLUSTER, REFRESH MATERIALIZED VIEW, and REINDEX. I plan to post that > tomorrow.
The fact that we just doubled the number of available bits doesn't mean we should immediately strive to use them up. Perhaps it'd be better to subsume these retail privileges under some generic "maintenance action" privilege?
In that message I review the history of permission bit growth. A bit later in the discussion, I did some investigation into the history of demand for new permission bits and I proposed calling the new privilege MAINTAIN:
For what it's worth, I wouldn't bother changing the format of the permission bits to expand the pool of available bits. 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. There is even justification for stopping after this expansion: if it is done, then schema changes (DDL) will only be able to be done by owner; data changes (insert, update, delete, as well as triggering of automatic data maintenance actions) will be able to be done by anybody who is granted permission.
My guess is that if we ever do expand the privilege bit system, it should be in a way that removes the limit entirely, replacing a bit map model with something more like a table with one row for each individual grant, with a field indicating which grant is involved. But that is a hypothetical future.
