Fix RLS checks for UPDATE/DELETE FOR PORTION OF leftover rows
Hi,
While revisiting “[8e72d914c] Add UPDATE/DELETE FOR PORTION OF”, I found a new issue where inserting leftover rows may skip row-level security checks.
This is a repro:
1. Prepare a role and a table with an int4range column, then add policies that require the lower bound to be less than 50:
```
evantest=# create role u;
CREATE ROLE
evantest=# create table t (id int, valid_at int4range);
CREATE TABLE
evantest=# alter table t enable row level security;
ALTER TABLE
evantest=# alter table t force row level security;
ALTER TABLE
evantest=# create policy t_sel on t for select to u using (true);
CREATE POLICY
evantest=# create policy t_upd on t for update to u using (lower(valid_at)<50) with check (lower(valid_at)<50);
CREATE POLICY
evantest=# create policy t_del on t for delete to u using (lower(valid_at)<50);
CREATE POLICY
evantest=# create policy t_ins on t for insert to u with check (lower(valid_at)<50);
CREATE POLICY
evantest=# grant select, update, delete, insert on t to u;
GRANT
evantest=# insert into t values (1, '[10,100)');
INSERT 0 1
evantest=# set role u;
SET
```
2. Update the row:
```
evantest=> update t for portion of valid_at from 30 to 70 set id=2;
UPDATE 1
evantest=> select * from t;
id | valid_at
----+----------
2 | [30,70)
1 | [10,30)
1 | [70,100)
(3 rows)
```
Here, the right leftover [70,100) was inserted, even though the INSERT policy requires lower(valid_at) < 50. If the policy were honored, the update should fail because the leftover insert violates policy t_ins.
After tracing the update statement, I think the problem is as follows.
1.In the rewrite phase, get_policies_for_relation() gets only the UPDATE policy, because commandType is CMD_UPDATE:
```
/*
* For SELECT, UPDATE and DELETE, add security quals to enforce the USING
* policies. These security quals control access to existing table rows.
* Restrictive policies are combined together using AND, and permissive
* policies are combined together using OR.
*/
get_policies_for_relation(rel, commandType, user_id, &permissive_policies,
&restrictive_policies);
…..
/*
* For INSERT and UPDATE, add withCheckOptions to verify that any new
* records added are consistent with the security policies. This will use
* each policy's WITH CHECK clause, or its USING clause if no explicit
* WITH CHECK clause is defined.
*/
if (commandType == CMD_INSERT || commandType == CMD_UPDATE)
{
/* This should be the target relation */
Assert(rt_index == root->resultRelation);
add_with_check_options(rel, rt_index,
commandType == CMD_INSERT ?
WCO_RLS_INSERT_CHECK : WCO_RLS_UPDATE_CHECK,
permissive_policies,
restrictive_policies,
withCheckOptions,
hasSubLinks,
false);
```
2. In ExecForPortionOfLeftovers(), before inserting a leftover row, it temporarily saves mtstate->operation and changes it to CMD_INSERT:
```
/*
* Save some mtstate things so we can restore them below. XXX:
* Should we create our own ModifyTableState instead?
*/
oldOperation = mtstate->operation;
mtstate->operation = CMD_INSERT;
oldTcs = mtstate->mt_transition_capture;
```
3. Then it calls ExecInsert() with that state to insert the leftover row:
```
/*
* The standard says that each temporal leftover should execute its
* own INSERT statement, firing all statement and row triggers, but
* skipping insert permission checks. Therefore we give each insert
* its own transition table. If we just push & pop a new trigger level
* for each insert, we get exactly what we need.
*
* We have to make sure that the inserts don't add to the ROW_COUNT
* diagnostic or the command tag, so we pass false for canSetTag.
*/
AfterTriggerBeginQuery();
ExecSetupTransitionCaptureState(mtstate, estate);
fireBSTriggers(mtstate);
ExecInsert(context, resultRelInfo, leftoverSlot, false, NULL, NULL);
fireASTriggers(mtstate);
AfterTriggerEndQuery(estate);
```
4. In ExecInsert(), wco_kind is chosen from mtstate->operation. Since it is now CMD_INSERT, the value becomes WCO_RLS_INSERT_CHECK:
```
/*
* Check any RLS WITH CHECK policies.
*
* Normally we should check INSERT policies. But if the insert is the
* result of a partition key update that moved the tuple to a new
* partition, we should instead check UPDATE policies, because we are
* executing policies defined on the target table, and not those
* defined on the child partitions.
*
* If we're running MERGE, we refer to the action that we're executing
* to know if we're doing an INSERT or UPDATE to a partition table.
*/
if (mtstate->operation == CMD_UPDATE)
wco_kind = WCO_RLS_UPDATE_CHECK;
else if (mtstate->operation == CMD_MERGE)
wco_kind = (mtstate->mt_merge_action->mas_action->commandType == CMD_UPDATE) ?
WCO_RLS_UPDATE_CHECK : WCO_RLS_INSERT_CHECK;
else
wco_kind = WCO_RLS_INSERT_CHECK;
```
5. With this wco_kind, it calls ExecWithCheckOptions():
```
/*
* ExecWithCheckOptions() will skip any WCOs which are not of the kind
* we are looking for at this point.
*/
if (resultRelInfo->ri_WithCheckOptions != NIL)
ExecWithCheckOptions(wco_kind, resultRelInfo, slot, estate);
```
6. In ExecWithCheckOptions(), it loops over all WithCheckOptions built during rewrite:
```
/* Check each of the constraints */
forboth(l1, resultRelInfo->ri_WithCheckOptions,
l2, resultRelInfo->ri_WithCheckOptionExprs)
{
WithCheckOption *wco = (WithCheckOption *) lfirst(l1);
ExprState *wcoExpr = (ExprState *) lfirst(l2);
/*
* Skip any WCOs which are not the kind we are looking for at this
* time.
*/
if (wco->kind != kind)
continue;
```
In this loop, wco->kind is WCO_RLS_UPDATE_CHECK, but kind is WCO_RLS_INSERT_CHECK, so the check is skipped and the right leftover row [70,100) is inserted.
The same problem exists for DELETE as well:
```
evantest=> delete from t for portion of valid_at from 30 to 70;
DELETE 1
evantest=> select * from t;
id | valid_at
----+----------
1 | [10,30)
1 | [70,100)
(2 rows)
```
For DELETE, in code snippet 1 above, add_with_check_options() is not called at all because commandType is CMD_DELETE. Then, in code snippet 5, resultRelInfo->ri_WithCheckOptions is NULL, so ExecWithCheckOptions() is not called.
I checked the docs, and they seem to mention only that INSERT privilege is not required for the hidden insertion of leftover rows. But I think RLS should still be honored, because otherwise the policies are violated. For example, directly inserting [70,100) is blocked by policy t_ins, but a user can work around that by inserting [1,100) and then updating [30,70), which seems like a security hole.
To fix this, I think the rewriter should load INSERT policies for UPDATE and DELETE operations when parse->forPortionOfexists, since UPDATE/DELETE FOR PORTION OF may insert leftover rows.
See the attached patch for details. With the fix, both the update and delete above now fail:
```
evantest=> update t for portion of valid_at from 30 to 70 set id=2;
ERROR: new row violates row-level security policy for table "t"
evantest=> delete from t for portion of valid_at from 30 to 70;
ERROR: new row violates row-level security policy for table "t"
```
BTW, I just saw that the v19 branch has been cut and HEAD is now v20, so it looks like this patch will need to be back-patched if accepted.
Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/
Hi,
On Tue, 30 Jun 2026 at 13:16, Chao Li <li.evan.chao@gmail.com> wrote:
Hi,
While revisiting “[8e72d914c] Add UPDATE/DELETE FOR PORTION OF”, I found a
new issue where inserting leftover rows may skip row-level security checks.
Please see if it is the same as this: PostgreSQL: Enforce INSERT RLS
checks for FOR PORTION OF leftovers?
</messages/by-id/CAJTYsWWdeBkoH5g8D-k9LDw9ciqsMxb21EJSiFXAzP4J=XyxOQ@mail.gmail.com>
If yes, it is already present in the PG 19 open list.
Regards,
Ayush
On Jun 30, 2026, at 15:51, Ayush Tiwari <ayushtiwari.slg01@gmail.com> wrote:
Hi,
On Tue, 30 Jun 2026 at 13:16, Chao Li <li.evan.chao@gmail.com> wrote:
Hi,While revisiting “[8e72d914c] Add UPDATE/DELETE FOR PORTION OF”, I found a new issue where inserting leftover rows may skip row-level security checks.
Please see if it is the same as this: PostgreSQL: Enforce INSERT RLS checks for FOR PORTION OF leftovers?
If yes, it is already present in the PG 19 open list.
Regards,
Ayush
Thanks for pointing that out. I didn’t notice that thread.
Yes, that’s the same issue. I saw Paul wrote this there:
```
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.
```
That explains why the ACL checks are skipped as stated in the doc, but I don’t think the same reasoning should apply to RLS checks. As I explained in my patch email, for example, directly inserting [70,100) is blocked by policy t_ins, but a user can work around that by inserting [1,100) and then updating [30,70), which seems like a security hole.
Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/
On Jun 30, 2026, at 16:00, Chao Li <li.evan.chao@gmail.com> wrote:
On Jun 30, 2026, at 15:51, Ayush Tiwari <ayushtiwari.slg01@gmail.com> wrote:
Hi,
On Tue, 30 Jun 2026 at 13:16, Chao Li <li.evan.chao@gmail.com> wrote:
Hi,While revisiting “[8e72d914c] Add UPDATE/DELETE FOR PORTION OF”, I found a new issue where inserting leftover rows may skip row-level security checks.
Please see if it is the same as this: PostgreSQL: Enforce INSERT RLS checks for FOR PORTION OF leftovers?
If yes, it is already present in the PG 19 open list.
Regards,
AyushThanks for pointing that out. I didn’t notice that thread.
Yes, that’s the same issue. I saw Paul wrote this there:
```
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.
```That explains why the ACL checks are skipped as stated in the doc, but I don’t think the same reasoning should apply to RLS checks. As I explained in my patch email, for example, directly inserting [70,100) is blocked by policy t_ins, but a user can work around that by inserting [1,100) and then updating [30,70), which seems like a security hole.
I just noticed that I forgot the attached again.
Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/
Attachments:
v1-0001-Fix-RLS-checks-for-FOR-PORTION-OF-leftover-rows.patchapplication/octet-stream; name=v1-0001-Fix-RLS-checks-for-FOR-PORTION-OF-leftover-rows.patch; x-unix-mode=0644Download+178-1
On Tue, Jun 30, 2026 at 1:08 AM Chao Li <li.evan.chao@gmail.com> wrote:
On Jun 30, 2026, at 16:00, Chao Li <li.evan.chao@gmail.com> wrote:
Yes, that’s the same issue. I saw Paul wrote this there:
```
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.
```That explains why the ACL checks are skipped as stated in the doc, but I don’t think the same reasoning should apply to RLS checks. As I explained in my patch email, for example, directly inserting [70,100) is blocked by policy t_ins, but a user can work around that by inserting [1,100) and then updating [30,70), which seems like a security hole.
I just noticed that I forgot the attached again.
Thank you for working on this!
I still think it is a weird inconsistency to check RLS policies when
we're skipping ACLs, but there are a couple things I like about it:
- It gives the user more choice. They can use the policy to make
whatever decision they want. So enforcing the policy offers a superset
of the functionality of not enforcing it (but see below).
- RLS is maybe more general than just permissions. Your examples
aren't really about permissions. You can write policies that are more
like CHECK constraints, but with selective enforcement. (OTOH is that
really a good idea?)
One thing I'm concerned about is this: if we apply INSERT policies for
UPDATE FOR PORTION OF, how do we support users who want to forbid
*adding new entities* but allow *changing the history of existing
entities*? By applying INSERT policies, we are blocking them from
both. So maybe this doesn't really offer a superset of functionality
after all. And I think my use case is fairly realistic. More realistic
than wanting to allow updates but not if they update only part of the
history.
If a policy had a way of discerning when an INSERT is for a temporal
leftover, then there would be no problem: the user could decide to let
those through. But I don't think we have a way to do that, do we? If
there might be a way to do it in the future, that would also alleviate
my concern here. I already have patches to expose FOR PORTION OF
parameters in TG_* variables. Maybe a policy could use something
similar.
@@ -393,6 +393,51 @@ get_row_security_policies(Query *root,
RangeTblEntry *rte, int rt_index,
}
}
+ /*
+ * UPDATE/DELETE FOR PORTION OF may insert leftover rows to preserve the
+ * portions of the old row not covered by the target range. Those hidden
+ * inserts go through ExecInsert(), so they need the same INSERT RLS WITH
+ * CHECK options as ordinary INSERTs.
+ */
+ if (root->forPortionOf != NULL && rt_index == root->resultRelation &&
+ (commandType == CMD_UPDATE || commandType == CMD_DELETE))
+ {
+ List *insert_permissive_policies;
+ List *insert_restrictive_policies;
+
+ get_policies_for_relation(rel, CMD_INSERT, user_id,
+ &insert_permissive_policies,
+ &insert_restrictive_policies);
+ add_with_check_options(rel, rt_index,
+ WCO_RLS_INSERT_CHECK,
+ insert_permissive_policies,
+ insert_restrictive_policies,
+ withCheckOptions,
+ hasSubLinks,
+ false);Is this the right way to do these checks? I'll try to look into it a
bit more today, but does this cause problems when an UPDATE *doesn't*
create leftovers?
We should update the documentation as well. I think it should point
out the contrast between ACLs and RLS here.
Yours,
--
Paul ~{:-)
pj@illuminatedcomputing.com
Is this the right way to do these checks? I'll try to look into it a
bit more today, but does this cause problems when an UPDATE *doesn't*
create leftovers?
I did some extra testing but couldn't find any problems. I looked at
INSERT policies when FOR PORTION OF exactly matches a row's bounds (so
the row is updated but there are no leftovers), and also INSERT
policies that include sublinks.
We should update the documentation as well. I think it should point
out the contrast between ACLs and RLS here.
Here is a v2 with a couple lines of documentation added.
Yours,
--
Paul ~{:-)
pj@illuminatedcomputing.com
Attachments:
v2-0001-Fix-RLS-checks-for-FOR-PORTION-OF-leftover-rows.patchapplication/octet-stream; name=v2-0001-Fix-RLS-checks-for-FOR-PORTION-OF-leftover-rows.patchDownload+182-3
Hi,
On Thu, 2 Jul 2026 at 23:36, Paul A Jungwirth <pj@illuminatedcomputing.com>
wrote:
Is this the right way to do these checks? I'll try to look into it a
bit more today, but does this cause problems when an UPDATE *doesn't*
create leftovers?I did some extra testing but couldn't find any problems. I looked at
INSERT policies when FOR PORTION OF exactly matches a row's bounds (so
the row is updated but there are no leftovers), and also INSERT
policies that include sublinks.We should update the documentation as well. I think it should point
out the contrast between ACLs and RLS here.Here is a v2 with a couple lines of documentation added.
I had reviewed v1 and it looked good to me, assuming v2
changes just added the RLS policies documentation update, the patch
addresses my concern and looks good to me!
Regards,
Ayush
On Jul 3, 2026, at 02:06, Paul A Jungwirth <pj@illuminatedcomputing.com> wrote:
Is this the right way to do these checks? I'll try to look into it a
bit more today, but does this cause problems when an UPDATE *doesn't*
create leftovers?I did some extra testing but couldn't find any problems. I looked at
INSERT policies when FOR PORTION OF exactly matches a row's bounds (so
the row is updated but there are no leftovers), and also INSERT
policies that include sublinks.We should update the documentation as well. I think it should point
out the contrast between ACLs and RLS here.Here is a v2 with a couple lines of documentation added.
Yours,
--
Paul ~{:-)
pj@illuminatedcomputing.com
<v2-0001-Fix-RLS-checks-for-FOR-PORTION-OF-leftover-rows.patch>
Thanks for testing and updating the doc. I agree the docs need to be updated.
I’d rephrase this a little bit:
```
RLS policies for inserting temporal leftovers are still checked.
```
Only INSERT policies will be checked, so I changed it to:
```
Row-level security INSERT policies are still checked for these leftover inserts.
```
PFA v3, only this tiny doc change.
Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/
Attachments:
v3-0001-Fix-RLS-checks-for-FOR-PORTION-OF-leftover-rows.patchapplication/octet-stream; name=v3-0001-Fix-RLS-checks-for-FOR-PORTION-OF-leftover-rows.patch; x-unix-mode=0644Download+182-3
On Thu, Jul 2, 2026 at 2:52 PM Chao Li <li.evan.chao@gmail.com> wrote:
Here is a v2 with a couple lines of documentation added.
Thanks for testing and updating the doc. I agree the docs need to be updated.
I’d rephrase this a little bit:
```
RLS policies for inserting temporal leftovers are still checked.
```Only INSERT policies will be checked, so I changed it to:
```
Row-level security INSERT policies are still checked for these leftover inserts.
```PFA v3, only this tiny doc change.
+1
--
Paul ~{:-)
pj@illuminatedcomputing.com
On Thu, 2 Jul 2026 at 22:57, Paul A Jungwirth
<pj@illuminatedcomputing.com> wrote:
On Thu, Jul 2, 2026 at 2:52 PM Chao Li <li.evan.chao@gmail.com> wrote:
PFA v3, only this tiny doc change.
+1
This should also update the doc table "Policies Applied by Command
Type" on the CREATE POLICY page. I'd suggest a new row for "UPDATE ...
FOR PORTION OF" immediately after the "UPDATE" row, rather than trying
to reuse the existing row with more conditions (and similarly for
DELETE).
Also, in the rowsecurity regression test, it would be a good idea to
add test cases to the "Test policies applied by command type" section.
Those tests are the confirmations that what that doc table says is
true (the patch's tests aren't really checking that the SELECT policy
is being applied, for example).
Regards,
Dean
On Wed, Jul 15, 2026 at 11:51 AM Dean Rasheed <dean.a.rasheed@gmail.com> wrote:
This should also update the doc table "Policies Applied by Command
Type" on the CREATE POLICY page. I'd suggest a new row for "UPDATE ...
FOR PORTION OF" immediately after the "UPDATE" row, rather than trying
to reuse the existing row with more conditions (and similarly for
DELETE).Also, in the rowsecurity regression test, it would be a good idea to
add test cases to the "Test policies applied by command type" section.
Those tests are the confirmations that what that doc table says is
true (the patch's tests aren't really checking that the SELECT policy
is being applied, for example).
Thanks for taking a look! Here is a v4 with those additions.
Yours,
--
Paul ~{:-)
pj@illuminatedcomputing.com
Attachments:
v4-0001-Fix-RLS-checks-for-FOR-PORTION-OF-leftover-rows.patchtext/x-patch; charset=US-ASCII; name=v4-0001-Fix-RLS-checks-for-FOR-PORTION-OF-leftover-rows.patchDownload+293-5
On Wed, 15 Jul 2026 at 22:02, Paul A Jungwirth
<pj@illuminatedcomputing.com> wrote:
Thanks for taking a look! Here is a v4 with those additions.
+ <entry><command>UPDATE ... FOR PORTION OF</command></entry>
+ <entry>
+ Filter existing row <footnoteref linkend="rls-select-priv"/> &
+ check new row <footnoteref linkend="rls-select-priv"/>
+ </entry>
+ <entry>The footnote "rls-select-priv" reads "If read access is required to
either the existing or new row (for example, a WHERE or RETURNING
clause that refers to columns from the relation)." However, FOR
PORTION OF is guaranteed to require read access to the table, so as
with a few other entries in that column, the link to this footnote is
not needed -- it will unconditionally apply the SELECT policy to the
existing and new rows. Similarly for DELETE ... FOR PORTION OF.
+ /*
+ * As with regular INSERT/UPDATE above, if SELECT rights are needed
+ * for the statement, ensure the leftover row remains visible.
+ */
+ if (perminfo->requiredPerms & ACL_SELECT)
+ {
+ List *select_permissive_policies;
+ List *select_restrictive_policies;
+
+ get_policies_for_relation(rel, CMD_SELECT, user_id,
+ &select_permissive_policies,
+ &select_restrictive_policies);
+ add_with_check_options(rel, rt_index,
+ WCO_RLS_INSERT_CHECK,
+ select_permissive_policies,
+ select_restrictive_policies,
+ withCheckOptions,
+ hasSubLinks,
+ true);
+ }Thinking some more about this, I'm not so sure it's right. For a plain
INSERT, we apply SELECT policies if SELECT permissions are required,
which only happens if there is a RETURNING clause. The reason is to
ensure the user has rights to see the row returned by the RETURNING
clause. However, for the auxiliary INSERTS for leftover portions in
UPDATE/DELETE ... FOR PORTION OF, even if there is a RETURNING clause,
it will only return the updated/deleted row, not the leftover rows.
The command never reads the leftover rows, so why do we need the
leftover rows to satisfy the SELECT policies?
Regards,
Dean
On Jul 16, 2026, at 08:26, Paul A Jungwirth <pj@illuminatedcomputing.com> wrote:
On Wed, Jul 15, 2026 at 4:40 PM Dean Rasheed <dean.a.rasheed@gmail.com> wrote:
On Wed, 15 Jul 2026 at 22:02, Paul A Jungwirth
<pj@illuminatedcomputing.com> wrote:Thanks for taking a look! Here is a v4 with those additions.
+ <entry><command>UPDATE ... FOR PORTION OF</command></entry> + <entry> + Filter existing row <footnoteref linkend="rls-select-priv"/> & + check new row <footnoteref linkend="rls-select-priv"/> + </entry> + <entry>The footnote "rls-select-priv" reads "If read access is required to
either the existing or new row (for example, a WHERE or RETURNING
clause that refers to columns from the relation)." However, FOR
PORTION OF is guaranteed to require read access to the table, so as
with a few other entries in that column, the link to this footnote is
not needed -- it will unconditionally apply the SELECT policy to the
existing and new rows. Similarly for DELETE ... FOR PORTION OF.Just to confirm: you're saying that because FOR PORTION OF always
filters rows, the "if" in the footnote is misleading? I can see that
argument, so I removed the footnote after "filter existing row" and
"check new row" from the new entries. Do you think I should add a
different footnote explaining that it is unconditional?+ /* + * As with regular INSERT/UPDATE above, if SELECT rights are needed + * for the statement, ensure the leftover row remains visible. + */ + if (perminfo->requiredPerms & ACL_SELECT) + { + List *select_permissive_policies; + List *select_restrictive_policies; + + get_policies_for_relation(rel, CMD_SELECT, user_id, + &select_permissive_policies, + &select_restrictive_policies); + add_with_check_options(rel, rt_index, + WCO_RLS_INSERT_CHECK, + select_permissive_policies, + select_restrictive_policies, + withCheckOptions, + hasSubLinks, + true); + }Thinking some more about this, I'm not so sure it's right. For a plain
INSERT, we apply SELECT policies if SELECT permissions are required,
which only happens if there is a RETURNING clause. The reason is to
ensure the user has rights to see the row returned by the RETURNING
clause. However, for the auxiliary INSERTS for leftover portions in
UPDATE/DELETE ... FOR PORTION OF, even if there is a RETURNING clause,
it will only return the updated/deleted row, not the leftover rows.
The command never reads the leftover rows, so why do we need the
leftover rows to satisfy the SELECT policies?I think you are right. I replaced that section with a comment.
v5 attached.
Yours,
--
Paul ~{:-)
pj@illuminatedcomputing.com
<v5-0001-Fix-RLS-checks-for-FOR-PORTION-OF-leftover-rows.patch>
Thanks Dean for the reviews.
Thanks Paul for updating the patch.
Actually, when I received v4, I was also working on addressing Dean’s comments.
I reviewed both v4 and v5, made some small adjustments, and here is v6:
* For the create_policy doc change, I changed “check new row” to “check leftover rows”.
* For the “SELECT rights” comment, I moved it into the block comment, because its position in v5 looked like a placeholder.
* For the tests, v4 and v5 added the new cases in the MERGE section. I added the test in a more direct section.
* For the tests, v4 and v5 granted INSERT privilege. V6 intentionally does not, because the test runs UPDATE/DELETE FOR PORTION OF, and INSERT privilege is not required for inserting leftover rows by design.
I also updated the commit message to add Paul as a co-author and Dean as a reviewer.
Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/
Attachments:
v6-0001-Fix-RLS-checks-for-FOR-PORTION-OF-leftover-rows.patchapplication/octet-stream; name=v6-0001-Fix-RLS-checks-for-FOR-PORTION-OF-leftover-rows.patch; x-unix-mode=0644Download+264-5
Import Notes
Reply to msg id not found: CA+renyWqKvB86R2FBAUh=AWoyt40qMf7yHWzoHaBr15kyy+Tjw@mail.gmail.com