Skip site navigation (1) Skip section navigation (2)


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: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackerspgsql-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

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


pgsql-hackers by date

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

pgsql-patches by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group