Re: table partitioning and access privileges

Поиск
Список
Период
Сортировка
От Amit Langote
Тема Re: table partitioning and access privileges
Дата
Msg-id CA+HiwqGCQLKizA+Voyw3GjRv0q8t9adS2YFGmw6GzAbRb+yazg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: table partitioning and access privileges  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: table partitioning and access privileges
Список pgsql-hackers
On Fri, Dec 27, 2019 at 4:26 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Fujii Masao <masao.fujii@gmail.com> writes:
> > My customer reported me that the queries through a partitioned table
> > ignore each partition's SELECT, INSERT, UPDATE, and DELETE privileges,
> > on the other hand, only TRUNCATE privilege specified for each partition
> > is applied. I'm not sure if this behavior is expected or not. But anyway
> > is it better to document that? For example,
>
> >     Access privileges may be defined and removed separately for each partition.
> >     But note that queries through a partitioned table ignore each partition's
> >     SELECT, INSERT, UPDATE and DELETE privileges, and apply only TRUNCATE one.
>
> I believe it's intentional that we only check access privileges on
> the table explicitly named in the query.  So I'd say SELECT etc
> are doing the right thing, and if TRUNCATE isn't in step with them
> that's a bug to fix, not something to document.

I tend to agree that TRUNCATE's permission model for inheritance
should be consistent with that for the other commands.  How about the
attached patch toward that end?

Thanks,
Amit

Вложения

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

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: Allow CLUSTER, VACUUM FULL and REINDEX to change tablespace onthe fly
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: pgbench - use pg logging capabilities