Re: table partitioning and access privileges

Поиск
Список
Период
Сортировка
От Amit Langote
Тема Re: table partitioning and access privileges
Дата
Msg-id CA+HiwqH7fWirNP=c776Rg4d5ivD2DMoEu-oQkLk8eaAKiqtk7w@mail.gmail.com
обсуждение исходный текст
Ответ на Re: table partitioning and access privileges  (Fujii Masao <masao.fujii@oss.nttdata.com>)
Ответы Re: table partitioning and access privileges  (Fujii Masao <masao.fujii@oss.nttdata.com>)
Список pgsql-hackers
On Thu, Feb 13, 2020 at 8:39 PM Fujii Masao <masao.fujii@oss.nttdata.com> wrote:
> On 2020/02/07 10:39, Amit Langote wrote:
> > On Fri, Feb 7, 2020 at 1:16 AM Fujii Masao <masao.fujii@oss.nttdata.com> wrote:
> >> Yes, so I will review your patch getting rid of
> >> LOCK TABLE exception.
> >
> > Attached updated patch.
>
> Thanks! This patch basically looks good to me except
> the following minor comment.
>
>   ROLLBACK;
> -BEGIN;
> -LOCK TABLE ONLY lock_tbl1;
> -ROLLBACK;
>   RESET ROLE;
>
> I think that there is no strong reason why these SQLs need to be
> removed. We can verify that even "LOCK TABLE ONLY" command works
> expectedly on the inherited tables by keeping those SQLs in the
> regression test. So what about not removing these SQLs?

Hmm, that test becomes meaningless with the behavior change we are
introducing, but I am okay with not removing it.

However, I added a test showing that locking child table directly doesn't work.

Attached updated patch.

Thanks,
Amit

Вложения

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

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: Marking some contrib modules as trusted extensions
Следующее
От: "Moon, Insung"
Дата:
Сообщение: Re: Exposure related to GUC value of ssl_passphrase_command