Re: Enforce INSERT RLS checks for FOR PORTION OF leftovers?

On Mon, May 4, 2026 at 4:29 AM Ayush Tiwari <ayushtiwari(dot)slg01(at)gmail(dot)com> wrote:
>
> On Sat, 2 May 2026 at 00:23, Ayush Tiwari <ayushtiwari(dot)slg01(at)gmail(dot)com> wrote:
>>
>> I found what looks like a discrepancy where UPDATE/DELETE FOR
>> PORTION OF commands bypass INSERT RLS WITH CHECK
>> policies when inserting temporal leftover rows. Not sure if it's already
>> flagged (could not find it in DL).
>>
>> While it is intentional that ExecForPortionOfLeftovers() skips INSERT ACL
>> permission checks, the leftover rows are newly inserted rows and should
>> still satisfy INSERT/ALL RLS policies unless I'm missing something.
>
> Sharing a SQL repro example:
>
> CREATE ROLE u;
> CREATE TABLE t (id int, valid_at daterange NOT NULL, name text);
> ALTER TABLE t ENABLE ROW LEVEL SECURITY;
> CREATE POLICY p_all ON t FOR ALL TO u USING (true) WITH CHECK (true);
> CREATE POLICY p_ins ON t FOR INSERT TO u WITH CHECK (false);
> GRANT SELECT, INSERT, UPDATE, DELETE ON t TO u;
> INSERT INTO t VALUES (1, daterange('2018-01-01','2020-01-01'), 'ok');
>
> SET ROLE u;
>
> -- (A) Fails as expected: new row violates row-level security policy
> INSERT INTO t VALUES (2, daterange('2018-01-01','2020-01-01'), 'ok');
>
> -- (B) Should fail the same way (creates leftover rows), but silently succeeds
> UPDATE t FOR PORTION OF valid_at FROM '2019-01-01' TO '2019-06-01'
> SET name = 'ok' WHERE id = 1;
>
> If this is expected we need to change the documentation of policy
> and if it is not, should we go with something like I shared in
> upthread, I can send a patch file if required.

Skipping the RLS checks to insert the leftovers seems like the correct
behavior to me, since we are skipping the ACL checks (per the
standard). Shouldn't it be consistent?

I think the reason we skip the checks is that semantically, the
leftovers aren't changing anything: they are preserving the history
that is already there.

I'm happy to write a doc patch to make this explicit. Does anyone
disagree about the correct behavior though?

Yours,

--
Paul ~{:-)
pj(at)illuminatedcomputing(dot)com