* Tom Lane ([EMAIL PROTECTED]) wrote: > Stephen Frost <[EMAIL PROTECTED]> 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
signature.asc
Description: Digital signature
