Re: Docs and tests for RLS policies applied by command type - Mailing list pgsql-hackers

From jian he
Subject Re: Docs and tests for RLS policies applied by command type
Date
Msg-id CACJufxGyyRybvr-5=oudf7U187t+7nMMwWjGdCUcvNNVYds2Ew@mail.gmail.com
Whole thread Raw
In response to Re: Docs and tests for RLS policies applied by command type  (Dean Rasheed <dean.a.rasheed@gmail.com>)
List pgsql-hackers
On Mon, Oct 27, 2025 at 7:26 PM Dean Rasheed <dean.a.rasheed@gmail.com> wrote:
>
> Updated patch attached.
>

hi.

TABLE, Policies Applied by Command Type
MERGE related change looks very similar to standalone INSERT/UPDATE/DELETE.
overall v3-0001 looks good to me.

while reading the doc, this description in UPDATE section:
"""
Note, however, that unlike a standalone UPDATE command, if the existing row does
not pass the USING expressions, an error will be thrown (the UPDATE path will
never be silently avoided).
""

I think the above statement also applies to MERGE ... THEN UPDATE.
Perhaps the table “Policies Applied by Command Type” already conveys this,
but I’m not sure.

below shows that MERGE ... THEN UPDATE USING expression does not pass will
result error

begin;
reset role;
drop table if exists tts;
create table tts(a int , b int);
insert into tts values (4, 5), (2,5), (3, 5);
CREATE POLICY p1 ON tts FOR SELECT USING (a < 3);
CREATE POLICY p3 ON tts FOR UPDATE USING (a > 3) WITH CHECK (b = 5);
grant all on tts to alice;
ALTER TABLE tts ENABLE ROW LEVEL SECURITY;
commit;

BEGIN;
SET ROLE alice;
MERGE INTO tts d USING (SELECT 2 as sdid) s ON a = s.sdid
WHEN MATCHED THEN
    UPDATE SET b = 5;
ROLLBACK;



pgsql-hackers by date:

Previous
From: shveta malik
Date:
Subject: Re: POC: enable logical decoding when wal_level = 'replica' without a server restart
Next
From: Michael Paquier
Date:
Subject: Re: Bug in pg_stat_statements