Re: Truncate Permission - Mailing list pgsql-hackers

From Nicholas Barr
Subject Re: Truncate Permission
Date
Msg-id 44180.62.244.190.66.1181744963.squirrel@www.chuckie.co.uk
Whole thread Raw
In response to Re: Truncate Permission  (Stephen Frost <sfrost@snowman.net>)
Responses Re: Truncate Permission  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
> * Zeugswetter Andreas ADI SD (ZeugswetterA@spardat.at) wrote:
>>
>> > > Wouldn't it be far more logical to decide that if a user has the
>> > > permissions to do a DELETE FROM table; then they have permission to
>> do
>> > > a TRUNCATE? Why make an additional permission?
>> >
>> > Truncate doesn't fire ON DELETE triggers.
>>
>> Yes, but it would imho be ok if there are'nt any on delete triggers on
>> the table.
>
> Nope, it doesn't follow MVCC rules properly either.  It really needs to
> be a seperate permission.
>
>     Thanks,
>
>         Stephen

Hi,

Thanks for all the replies. I was primarily looking for some development
to do in my spare time, and have since produced a patch for this. I assume
this patch will be put on hold, which is fine.

Would the core developers accept a patch that extended the ACL types to
support more possible permissions?

At the moment it seems as if a single 32 bit integer is used for the
permissions, with the top half being the grantable rights. I assume I
would need to extend this into two 32 bit integers, or one 64 bit integer?

Would it be worth making this two 64 bit integers whilst we are at it, or
is that just silly? I agree that making a permission for every possible
command would be overkill and somewhat time consuming, so I assume that
two 64 bit integers would also be overkill.


Nick




pgsql-hackers by date:

Previous
From: Gregory Stark
Date:
Subject: Re: Load Distributed Checkpoints test results
Next
From: Dave Page
Date:
Subject: Re: EXPLAIN omits schema?