> On Sep 7, 2022, at 3:21 PM, Nathan Bossart <nathandbossart@gmail.com> wrote:
>
> There was some previous discussion around adding a pg_maintenance role that
> could perform all of these commands [0]. I didn't intend to draw a line
> around VACUUM and ANALYZE. Those are just the commands I started with.
> If/when there are many of these roles, it might make sense to create a
> pg_maintenance role that is a member of pg_vacuum_all_tables,
> pg_analyze_all_tables, etc.
Thank you, that sounds fair enough.
It seems you've been pushed to make the patch-set more complicated, and now we're debating privilege bits, which seems
prettyfar off topic.
I may be preaching to the choir here, but wouldn't it work to commit new roles pg_vacuum_all_tables and
pg_analyze_all_tableswith checks like you had in the original patch of this thread? That wouldn't block the later
additionof finer grained controls allowing users to grant VACUUM or ANALYZE per-relation, would it? Something like
whatStephen is requesting, and what you did with new privilege bits for VACUUM and ANALYZE could still be added, unless
I'mmissing something.
I'd hate to see your patch set get further delayed by things that aren't logically prerequisites. The conversation
upthreadwas useful to determine that they aren't prerequisites, but if anybody wants to explain to me why they are....
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
