On Thu, Aug 27, 2026 at 10:57 AM Richard Guo <[email protected]> wrote: > That is a fair point. The only rels we can remove are plain relations > and subqueries, and the subqueries are now set to NULL, so a Var of a > removed rel should never be left in the tree. It is good to have the > Asserts to check that.
I found one more place where the new Assert fires. If the removed rel has RLS policies, its RTE still carries the RLS quals, and those quals contain Vars of the rel. ChangeVarNodes walks RTE.securityQuals, so we hit the Assert. As an example, run the query below in rowsecurity.sql: EXPLAIN (COSTS OFF) SELECT c.cid FROM category c LEFT JOIN document d ON c.cid = d.did; I think we can fix it by setting securityQuals to NIL next to where we set subquery to NULL for the removed RTE. I checked the other fields of RangeTblEntry and did not find any similar issue. The only other expression field that seems suspicious is tablesample, but I believe it's safe, as its arguments cannot refer to any rel of the same query level, so they never contain Vars we need to change. I've updated the delta patch to include the fix to this issue, along with a test case. - Richard
nocfbot.delta-v6.patch
Description: Binary data
