* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> Stephen Frost <sfrost@snowman.net> 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
