* 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