We can set this up once and for all in subquery_planner's initial survey
of the flattened rangetable, rather than incrementally adjusting it in
build_simple_rel. The previous approach made it rather hard to reason
about exactly when the value would be available, and we were definitely
using it in some places before the final value was computed.
Noted while fooling around with Amit Langote's patch to delay creation
of inheritance child rels. That didn't break this code, but it made it
even more fragile, IMO.
if (rte->lateral)
root->hasLateralRTEs = true;
+
+ /*
+ * We can also determine the maximum security level required for any
+ * securityQuals now. Addition of inheritance-child RTEs won't affect
+ * this, because child tables don't have their own securityQuals; see
+ * expand_single_inheritance_child().
+ */
+ if (rte->securityQuals)
+ root->qual_security_level = Max(root->qual_security_level,
+ list_length(rte->securityQuals));
}
/*
break;
}
- /*
- * This is a convenient spot at which to note whether rels participating
- * in the query have any securityQuals attached. If so, increase
- * root->qual_security_level to ensure it's larger than the maximum
- * security level needed for securityQuals. (Must do this before we call
- * apply_child_basequals, else we'll hit an Assert therein.)
- */
- if (rte->securityQuals)
- root->qual_security_level = Max(root->qual_security_level,
- list_length(rte->securityQuals));
-
/*
* Copy the parent's quals to the child, with appropriate substitution of
* variables. If any constant false or NULL clauses turn up, we can mark