Re: Skip ExecCheckRTPerms in CTAS with no data

From: Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Anastasia Lubennikova <a(dot)lubennikova(at)postgrespro(dot)ru>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Skip ExecCheckRTPerms in CTAS with no data
Date: 2020-11-11 08:04:05
Message-ID: CALj2ACXZ+00JJ+MfHqYcENggVpkCEeCK-TQziJ0iYfwz-52e+g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Nov 11, 2020 at 12:05 PM Michael Paquier <michael(at)paquier(dot)xyz> wrote:
>
> On Mon, Nov 09, 2020 at 10:48:09PM +0300, Anastasia Lubennikova wrote:
> > I see Tom's objection above. Still, I tend to agree that if 'WITH NO DATA'
> > was specified explicitly, CREATE AS should behave more like a utility
> > statement rather than a regular query. So I think that this patch can be
> > useful in some use-cases and I definitely don't see any harm it could cause.
> > Even the comment in the current code suggests that it is an option.
>
> I agree with Tom's point to leave this stuff alone, and just remove
> this XXX comment. An extra issue I can see is that you would bypass
> ExecutorCheckPerms_hook_type when using WITH NO DATA. This could
> silently break the users of this hook.
>

The ExecCheckRTPerms() with ACL_INSERT permission will be called
before inserting the data to the table that's created with CREATE AS
WITH NO DATA. The insertion into the table can happen either with
INSERT command(ExecCheckRTPerms() with ACL_INSERT permission will be
called from InitPlan()) or with COPY FROM command(ExecCheckRTPerms()
with ACL_INSERT permission will be called from DoCopy()).

Effectively, we are not bypassing the call to
ExecutorCheckPerms_hook_type. Unless I miss anything else, I think it
makes sense to skip ExecCheckRTPerms() for CTAS WITH NO DATA.

With Regards,
Bharath Rupireddy.
EnterpriseDB: http://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kyotaro Horiguchi 2020-11-11 08:33:17 In-placre persistance change of a relation
Previous Message tsunakawa.takay@fujitsu.com 2020-11-11 07:20:15 RE: POC: postgres_fdw insert batching