Re: table partitioning and access privileges

On 2020/02/14 10:28, Amit Langote wrote:
> 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.

Only this regression test seems to verify LOCK TABLE ONLY command.
So if we remove this, I'm afraid that the test coverage would be reduced.

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

Thanks for updating the patch!
Barring any objection, I will commit the patch.

Regards,

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