Re: Regarding TODO item "%Add a separate TRUNCATE permission"

* Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
> Stephen Frost <sfrost(at)snowman(dot)net> writes:
> > we need
> > to redesign the permission system to allow for more permission bits
> > because otherwise we'll run out soon.
>
> Only if we keep inventing separate privileges for things as specific
> as TRUNCATE. I was just about to raise this point as a possible reason
> why not to invent a separate TRUNCATE bit. (There are other problems,
> eg both 't' and 'T' letters are already taken.)

Unfortunately the things which (I feel anyway) we should be allowing
as grantable permissions really do fall into different categorizations
(imv). TRUNCATE violates MVCC so is more than just DELETE (and I could
definitely see where you might want to allow DELETE and *not* TRUNCATE).
Additionally, I think you need more then SELECT for 'ANALYZE' or
'VACUUM'. I could maybe see associating ANALYZE/VACUUM privileges with
privileges which can modify the table or with a new bit for both of
them. I could also see TRUNCATE having that ability but I do believe
that it'd be useful to be able to grant ANALYZE/VACUUM without granting
TRUNCATE...

> The question that really ought to be answered before doing any of this
> is why DELETE privilege shouldn't be sufficient to allow TRUNCATE.

TRUNCATE doesn't follow MVCC...

> In any case, I don't feel it necessary to panic about running out of
> permission bits when the space is only 75% used... with a little care
> it'll last us a long time yet, and I'm not eager to pay any performance
> price whatsoever just so we can invent the Joe Hacker Memorial Privilege
> Bit.

Splitting the privileges I don't think would incur any real performance
hit at all but I'd rather use up the bits we have before changing
things. I got the impression previously that the privilege system would
need to be changed before adding more things to the current system would
be allowed though.

Thanks,

Stephen