Re: table partitioning and access privileges

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:
>> On 2020/02/03 14:26, Amit Langote wrote:
>>> On Mon, Feb 3, 2020 at 2:07 PM Fujii Masao <masao.fujii@oss.nttdata.com> wrote:
>>>> On 2020/02/03 11:05, Amit Langote wrote:
>>>>> Okay.  How about the attached?
>>>>
>>>> Thanks for the patches! You added the note just after the description
>>>> about row level security on inherited table, but isn't it better to
>>>> add it before that? Attached patch does that. Thought?
>>>
>>> Yeah, that might be a better flow for that paragraph.
>>
>> Pushed! Thanks!
> 
> Thank you.
> 
>>>>> Maybe, we should also note the LOCK TABLE exception?
>>>>
>>>> Yes.
>>>
>>> Note that, unlike TRUNCATE, LOCK TABLE exception exists in HEAD too,
>>> but maybe you're aware of that.
>>
>> 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?

Regards,

-- 
Fujii Masao
NTT DATA CORPORATION
Advanced Platform Technology Group
Research and Development Headquarters