Re: RLS makes COPY TO process child tables - Mailing list pgsql-hackers

From Yugo NAGATA
Subject Re: RLS makes COPY TO process child tables
Date
Msg-id 20230202011525.c7c05900bcf791f868d72a51@sraoss.co.jp
Whole thread Raw
In response to RLS makes COPY TO process child tables  (Antonin Houska <ah@cybertec.at>)
Responses Re: RLS makes COPY TO process child tables
Re: RLS makes COPY TO process child tables
List pgsql-hackers
On Wed, 01 Feb 2023 12:45:57 +0100
Antonin Houska <ah@cybertec.at> wrote:

> While working on [1] I noticed that if RLS gets enabled, the COPY TO command
> includes the contents of child table into the result, although the
> documentation says it should not:
> 
>     "COPY TO can be used only with plain tables, not views, and does not
>     copy rows from child tables or child partitions. For example, COPY
>     table TO copies the same rows as SELECT * FROM ONLY table. The syntax
>     COPY (SELECT * FROM table) TO ... can be used to dump all of the rows
>     in an inheritance hierarchy, partitioned table, or view."
> 
> A test case is attached (rls.sql) as well as fix proposal
> (copy_rls_no_inh.diff).

I think this is a bug because the current behaviour is different from
the documentation. 

When RLS is enabled on a table in `COPY ... TO ...`, the query is converted
to `COPY (SELECT * FROM ...) TO ...` to allow the rewriter to add in RLS
clauses. This causes to dump the rows of child tables.

The patch fixes this by setting "inh" of the table in the converted query
to false. This seems reasonable and actually fixes the problem.

However, I think we would want a comment on the added line. Also, the
attached test should be placed in the regression test.

Regards,
Yugo Nagata

> 
> [1] https://commitfest.postgresql.org/41/3641/
> 
> -- 
> Antonin Houska
> Web: https://www.cybertec-postgresql.com
> 


-- 
Yugo NAGATA <nagata@sraoss.co.jp>



pgsql-hackers by date:

Previous
From: Nathan Bossart
Date:
Subject: Re: Weird failure with latches in curculio on v15
Next
From: Tom Lane
Date:
Subject: pg_dump versus hash partitioning