Re: Must be owner to truncate?
Stephen Frost <sfrost@snowman.net>
From: Stephen Frost <sfrost@snowman.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Postgres Hackers <pgsql-hackers@postgresql.org>
Date: 2005-07-07T18:02:05Z
Lists: pgsql-hackers
* Tom Lane (tgl@sss.pgh.pa.us) wrote: > Stephen Frost <sfrost@snowman.net> writes: > > The current permissions checks for truncate seem to be excessive. It > > requires that you're the owner of the relation instead of requiring > > that you have delete permissions on the relation. It was pointed out > > that truncate doesn't call triggers but it seems like that would be > > something easy enough to check for. > > There are other reasons for restricting it: > * truncate takes a much stronger lock than a plain delete does. What permissions are required to lock a table? With just select, insert, update and delete on a table I can LOCK TABLE it, which acquires an ACCESS EXCLUSIVE on it and will therefore hold off anyone else from using the table till the end of my transaction anyway. So I don't see this as being a reason to disallow non-owners use of truncate. > * truncate is not MVCC-safe. Erm, that's why it gets a stronger lock, so I don't really see what this has to do with it. > I don't really agree with the viewpoint that truncate is just a quick > DELETE, and so I do not agree that DELETE permissions should be enough > to let you do a TRUNCATE. Truncate is exactly a quick DELETE, in fact, DELETE could stand to learn some thing from truncate to make it suck a little less to 'delete from x;' when x is a reasonably large table. This probably wouldn't actually be all that difficult to do if there's a way to keep the old file around until all the transactions using it have completed that's not too expensive, etc. Thanks, Stephen