Re: table partitioning and access privileges - Mailing list pgsql-hackers

From Amit Langote
Subject Re: table partitioning and access privileges
Date
Msg-id CA+HiwqH7fWirNP=c776Rg4d5ivD2DMoEu-oQkLk8eaAKiqtk7w@mail.gmail.com
Whole thread Raw
In response to Re: table partitioning and access privileges  (Fujii Masao <masao.fujii@oss.nttdata.com>)
Responses Re: table partitioning and access privileges
List 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

Attachment

pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Marking some contrib modules as trusted extensions
Next
From: "Moon, Insung"
Date:
Subject: Re: Exposure related to GUC value of ssl_passphrase_command