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

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 04:32:01
Message-ID: 29096.1136349121@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
Stephen Frost <sfrost(at)snowman(dot)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?

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.

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: David FetterDate: 2006-01-04 04:34:04
Subject: Re: Deferrable UNIQUE INDEX?
Previous:From: Bruce MomjianDate: 2006-01-04 04:24:09
Subject: Re: [Bizgres-general] WAL bypass for INSERT, UPDATE and

pgsql-patches by date

Next:From: davegDate: 2006-01-04 06:37:56
Subject: Re: TRUNCATE, VACUUM, ANALYZE privileges
Previous:From: Stephen FrostDate: 2006-01-04 03:44:58
Subject: TRUNCATE, VACUUM, ANALYZE privileges

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