Re: Truncate Permission

Поиск
Список
Период
Сортировка
От Nicholas Barr
Тема Re: Truncate Permission
Дата
Msg-id 44180.62.244.190.66.1181744963.squirrel@www.chuckie.co.uk
обсуждение исходный текст
Ответ на Re: Truncate Permission  (Stephen Frost <sfrost@snowman.net>)
Ответы Re: Truncate Permission  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Gregory Stark
Дата:
Сообщение: Re: Load Distributed Checkpoints test results
Следующее
От: Dave Page
Дата:
Сообщение: Re: EXPLAIN omits schema?