Re: TRUNCATE, VACUUM, ANALYZE privileges

Stephen Frost <sfrost(at)snowman(dot)net> writes:
> GRANT ADD COLUMN, etc, aren't maintenance commands, they're DDL
> statements and as such should be the purview of the owner. TRUNCATE,
> VACUUM and ANALYZE are DML commands and are commands a user of
> the table would use through the normal course of inserting, updating or
> deleteing data in the table.

I find this reasoning fairly dubious. In particular, it's hard to argue
that there is no DDL component to TRUNCATE when it effectively does an
implicit disable-triggers operation. Another thing setting TRUNCATE
apart from run-of-the-mill DDL operations is that it inherently violates
MVCC rules (by deleting rows that should still be visible to concurrent
transactions).

But my real problem with the approach is that I don't see where it
stops. If you're allowed to do ANALYZE, why not ALTER TABLE SET
STATISTICS? If you're allowed to do TRUNCATE, why not the
recently-discussed ALTER TABLE SET RELIABILITY? And how about CLUSTER?
All of these could be pretty useful for some applications not too far
removed from yours. And there will be someone wanting a bit for
DISABLE/ENABLE TRIGGER coming along right afterwards. Must we implement
a separate nonstandard privilege bit for every operation that someone
comes up and wants a bit for, if they have the necessary cut-and-paste
skill to submit a patch for it?

I'd feel happier about an approach that adds *one* privilege bit
covering a range of operations that we agree to be useful. This will
avoid chewing a disproportionate amount of ACL storage space, and it
will force us to confront the decision about which operations are out
as well as which are in.

One last point: -patches is not the place for this type of discussion.

regards, tom lane