* Tom Lane ([EMAIL PROTECTED]) wrote: > Stephen Frost <[EMAIL PROTECTED]> writes: > > The following patch implements individual privileges for TRUNCATE, > > VACUUM and ANALYZE. Includes documentation and regression test > > updates. Resolves TODO item 'Add a separate TRUNCATE permission'. > > > At least the 'no one interested has written a patch' argument is gone > > now, fire away with other comments/concerns. :) > > I have a very serious problem with the idea of inventing individual > privilege bits for every maintenance command in sight. That does not > scale. How will you handle "GRANT ADD COLUMN", or "GRANT ADD COLUMN > as-long-as-its-not-SERIAL-because-I-dont-want-you-creating-sequences", > or "GRANT ALTER TABLE RELIABILITY" as soon as someone writes that patch, > or a dozen other cases that I could name without stopping for breath?
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. > The proposed patch eats three of the five available privilege bits (that > is, available without accepting the distributed cost of enlarging ACL > bitmasks), and you've made no case at all why we should spend that > limited resource in this particular fashion. I've shown a specific use-case for this. It's been asked for before by others. I've shown why these particular ones make sense (while 'ADD COLUMN', etc, don't). If we come up with more Postgres-specific DML statements which aren't covered by other grants (which doesn't seem terribly likely at this point) then we should add those. I could see making VACUUM and ANALYZE use the same bit (since one implies the other) but I'm not really a big fan of that and I don't see any other need for these bits coming down the line anytime soon. Thanks, Stephen
Description: Digital signature