Re: COPY FROM with RLS

On Tue, Oct 28, 2025 at 8:12 PM jian he <jian.universality@gmail.com> wrote:
>
> hi.
>
> While working on other COPY related patches, I wonder
> whether it's doable to implement RLS for COPY FROM.
>
> COPY FROM is more simple that INSERT. we don't need to consider
> INSERT RETURNING and INSERT ON CONFLICT DO UPDATE,
> also no need to worry about MERGE ... INSERT.
> we also don't need to consider SELECT privilege.
> security policy only applies to table and partitioned tables, so don't
> need to worry about
> VIEW INSTEAD OF TRIGGER and foreign tables.
>
> However, there's another complication that makes implementation difficult — a
> policy can contain a subquery.
> I'm not sure how to handle that properly, so error out whenever a policy
> contains a sublink/subquery. (maybe it's doable, seems hard....).
>

Hi. I implemented a hack to make it work with RLS policies that
contain subqueries; I'm not sure how valid it is.

IF  (check_enable_rls(RelationGetRelid(cstate->rel), InvalidOid,
false) == RLS_ENABLED)
is true, then we construct a dummy query string:

INSERT INTO "%s"."%s" DEFAULT VALUES

(where %s.%s is replaced by the schema-qualified relation name) and
then run it through the following pipeline:
pg_analyze_and_rewrite_fixedparams()
pg_plan_query()
CreateQueryDesc()
ExecutorStart()

Obviously, ExecutorRun() cannot be used because the data source for COPY FROM is
an external file rather than a normal query execution.

The main hack is to bypass ExecutorRun() completely and only use ExecutorStart()
to initialize the required executor structures (EState, PlanState,
ResultRelInfo, etc.) for ExecWithCheckOptions (which is part of
ExecutorRun normally).

In DoCopy we did converting COPY (REL) TO,to a SelectStmt  when REL have RLS.



--
jian
https://www.enterprisedb.com/