Re: TRUNCATE, VACUUM, ANALYZE privileges

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Stephen Frost <sfrost(at)snowman(dot)net>
Cc: PostgreSQL Patches <pgsql-patches(at)postgresql(dot)org>
Subject: Re: TRUNCATE, VACUUM, ANALYZE privileges
Date: 2006-01-04 16:11:15
Message-ID: 3109.1136391075@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2006-01-04 16:40:02 Re: postmaster/postgres options assimilation plan
Previous Message Peter Eisentraut 2006-01-04 15:33:57 postmaster/postgres options assimilation plan

Browse pgsql-patches by date

  From Date Subject
Next Message Josh Berkus 2006-01-04 19:41:36 Re: Inconsistent syntax in GRANT
Previous Message Stephen Frost 2006-01-04 11:55:44 Re: TRUNCATE, VACUUM, ANALYZE privileges