Re: LOCK TABLE Permissions

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: LOCK TABLE Permissions
Дата
Msg-id CA+Tgmob+SKNjK4FW81ejZpxOxsTVZJT8h_4u=xJyDb_-HBP7GQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: LOCK TABLE Permissions  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Fri, Jul 19, 2013 at 12:33 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Stephen Frost <sfrost@snowman.net> writes:
>>     if (lockmode == AccessShareLock)
>>         aclresult = pg_class_aclcheck(reloid, GetUserId(),
>>                                       ACL_SELECT);
>> +   else if (lockmode == RowExclusiveLock)
>> +       aclresult = pg_class_aclcheck(reloid, GetUserId(),
>> +                        ACL_INSERT | ACL_UPDATE | ACL_DELETE | ACL_TRUNCATE);
>>     else
>>         aclresult = pg_class_aclcheck(reloid, GetUserId(),
>>                                       ACL_UPDATE | ACL_DELETE | ACL_TRUNCATE);
>
> Perhaps it would be better to refactor with a local variable for the
> aclmask and just one instance of the pg_class_aclcheck call.  Also, I'm
> pretty sure that the documentation work needed is more extensive
> than the actual patch ;-).  Otherwise, I don't see a problem with this.

I don't really care one way or the other whether we change this in
master, but I think back-patching changes that loosen security
restrictions is a poor idea.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: getting rid of SnapshotNow
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: getting rid of SnapshotNow