* Tom Lane ([EMAIL PROTECTED]) wrote: > Nick Barr <[EMAIL PROTECTED]> writes: > > I was looking to start development on the following TODO entry. > > Add a separate TRUNCATE permission > > Is there actually a use-case for that? It seems like mostly pointless > complication to me. (Note that in the role world, one can effectively > have a table owned by a group, so the real issue here is only whether > there is a point in letting someone truncate a table without having any > other owner-grade permissions for it.)
Yes, there is a use-case for it. If you don't have triggers or transactional concerns on the table and you want users to be able to truncate tables while not allowing them to do things like change the table structure. I proposed a patch a while ago to implement a seperate permission for truncate but it was turned down because of concern over using the few remaining bits in the ACL structure. My counter-proposal is that the ACLs be split up into two integers instead of having just one- one for the 'use' bits and a seperate one for the 'GRANTABLE' bits. This would double the space available for permission bits and we could support truncate, vacuum, analyze all as seperate grantable permissions rather than forcing them to be lumped in with the ownership/ALTER TABLE permissions. Unfortunately, I havn't had time to actually implement this. I started on it but all the macros are pretty hard-wired towards the current implementation and their API isn't suited towards splitting the GRANTABLE parts out (iirc anyway, it's been a while). If we could agree on this approach perhaps we could add it as a TODO with a dependency on it before the seperate TRUNCATE permission is implemented. In fact, I brought this up previously in this thread that came up last year: http://archives.postgresql.org/pgsql-hackers/2006-04/msg00964.php Looking back farther, my patch originally added seperate permissions for TRUNCATE, VACUUM and ANALYZE here: http://archives.postgresql.org/pgsql-patches/2006-01/msg00028.php And the concern was about adding too many extra seperate permissions and about using up too many of the remaining privilege bits. There was an alternative suggestion to have one bit for 'truncate/vacuum/analyze/whatever-else-we-want' which might be alright in some cases but I don't like it because it's implied that it could change over time as we add things and that doesn't really sit very well with me. Also, it sounds an awful lot like 'almost owner' and I'm not exactly sure what we'd call it anyway. With auto-vacuum I'm a bit less concerned about having seperately grantable 'analyze' and 'vacuum' permissions (though I'd still like) so perhaps we can agree to use one bit up for a specific 'TRUNCATE' permission? Doesn't matter to me who implements it, but my patch might be a decent place to start looking at the areas which have to be touched. I'd also be happy to update/change it for current HEAD and to just implement the 'TRUNCATE' permission. I dunno, given that it's on the TODO and that we've had a patch (at least in part) for it for over a year, could it get into 8.4? ;) Thanks, Stephen
signature.asc
Description: Digital signature
