At 2026-05-10 14:23:26, "jian he" <[email protected]> wrote: >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.
Hi, I've gone through your v2 patch and there’s an issue I’d like to point out. In src/test/regress/expected/rowsecurity.out: +-- COPY FROM should also apply INSERT CHECK policy clause +COPY rls_test_tgt FROM STDIN WITH (DELIMITER ','); +ERROR: missing data for column "c" +CONTEXT: COPY rls_test_tgt, line 1: "1,tgt a" This "missing data for column c" error is actually a COPY formatting error, not an RLS policy violation. Best regards, -- Yilin Zhang
