From: Tom Lane <tgl@sss.pgh.pa.us>
To: Fujii Masao <masao.fujii@gmail.com>
cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: table partitioning and access privileges
In-reply-to: 
 <CAHGQGwFHdSvifhJE+-GSNqUHSfbiKxaeQQ7HGcYz6SC2n_oDcg@mail.gmail.com>
References: 
 <CAHGQGwFHdSvifhJE+-GSNqUHSfbiKxaeQQ7HGcYz6SC2n_oDcg@mail.gmail.com>
Comments: In-reply-to Fujii Masao <masao.fujii@gmail.com>
	message dated "Thu, 26 Dec 2019 15:37:52 +0900"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <6217.1577388354.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Thu, 26 Dec 2019 14:25:54 -0500
Message-ID: <6218.1577388354@sss.pgh.pa.us>
Precedence: bulk

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 par=
tition.
>     But note that queries through a partitioned table ignore each partit=
ion's
>     SELECT, INSERT, UPDATE and DELETE privileges, and apply only TRUNCAT=
E 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.

			regards, tom lane