> On Sep 7, 2022, at 3:21 PM, Nathan Bossart <nathandboss...@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 pretty far 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_tables with checks like you had in the
original patch of this thread? That wouldn't block the later addition of finer
grained controls allowing users to grant VACUUM or ANALYZE per-relation, would
it? Something like what Stephen is requesting, and what you did with new
privilege bits for VACUUM and ANALYZE could still be added, unless I'm missing
something.
I'd hate to see your patch set get further delayed by things that aren't
logically prerequisites. The conversation upthread was 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
