Re: LOCK TABLE Permissions

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: LOCK TABLE Permissions
Дата
Msg-id CAB7nPqSt_Q=_G26NoxnQwj+6316TvwV0MGCiaP3M1e6ojDKjLA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: LOCK TABLE Permissions  (Stephen Frost <sfrost@snowman.net>)
Ответы Re: LOCK TABLE Permissions  (Stephen Frost <sfrost@snowman.net>)
Список pgsql-hackers
On Tue, May 12, 2015 at 4:01 AM, Stephen Frost <sfrost@snowman.net> wrote:
> * Michael Paquier (michael.paquier@gmail.com) wrote:
>> On Mon, May 11, 2015 at 10:32 PM, Stephen Frost <sfrost@snowman.net> wrote:
>> > Now for a blast from the past...  This came up again on IRC recently and
>> > reminded me that I ran into the same issue a couple years back.  Updated
>> > patch includes the refactoring suggested and includes documentation.
>> >
>> > Barring objections, I'll push this later today.
>>
>> Small suggestion: a test case in src/test/isolation?
>
> This is entirely a permissions-related change and src/test/isolation is
> for testing concurrent behavior, not about testing permissions.
>
> I'm not saying that we shouldn't have more tests there, but it'd not
> be appropriate for this particular patch.

Perhaps. Note that we could have tests of this type though in lock.sql:
create role foo login;
create table aa (a int);
grant insert on aa TO foo;
\c postgres foo
begin;
insert into aa values (1);
lock table aa in row exclusive mode; -- should pass

Just mentioning it for the sake of the archives, I cannot work on that for now.
Regards,
-- 
Michael



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

Предыдущее
От: Stephen Frost
Дата:
Сообщение: Re: LOCK TABLE Permissions
Следующее
От: Stephen Frost
Дата:
Сообщение: Re: LOCK TABLE Permissions