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
