Re: Skip ExecCheckRTPerms in CTAS with no data

From: Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Skip ExecCheckRTPerms in CTAS with no data
Date: 2020-09-29 11:39:06
Message-ID: CALj2ACWCp_nFikL7UCgpwMAK0+t+vq5K8xgCRAVZbRm+nzp06w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Sep 28, 2020 at 7:48 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com> writes:
> > In case of CTAS with no data, we actually do not insert the tuples
> > into the created table, so we can skip checking for the insert
> > permissions. Anyways, the insert permissions will be checked when the
> > tuples are inserted into the table.
>
> I'd argue this is wrong. You don't get to skip permissions checks
> in ordinary queries just because, say, there's a LIMIT 0 on the
> query.
>

Right, when there's a select with limit 0 clause, we do check for the
select permissions. But my point is, we don't check insert
permissions(or select or update etc.) when we create a plain table
using CREATE TABLE test_tbl(a1 INT). Of course, we do check create
permissions. Going by the similar point, shouldn't we also check only
create permission(which is already being done as part of
DefineRelation) and skip the insert permission(the change this patch
does) for the new table being created as part of CREATE TABLE test_tbl
AS SELECT * FROM test_tbl2? However select permission will be checked
for test_tbl2. The insert permissions will be checked anyways before
inserting rows into the table created in CTAS.

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2020-09-29 12:00:13 Re: Corner-case bug in pg_rewind
Previous Message Ajin Cherian 2020-09-29 11:37:59 Re: [HACKERS] logical decoding of two-phase transactions