Hi,
designing things upon fresh master I found that varnullingrels contains
numbers that is out of the outer joins index range.
Anywhere in documentation I see that this field contains outer join
relids. But after the 247dea8 it simply isn't true.
So, I propose at least to change comments (see attachment). Since the
doc was out of scope, I wonder if someone analysed the impact of this
change on the whole optimiser logic.
--
regards, Andrei Lepikhov
diff --git a/src/backend/optimizer/README b/src/backend/optimizer/README
index 21c2db5a85c..c53cc7aee7f 100644
--- a/src/backend/optimizer/README
+++ b/src/backend/optimizer/README
@@ -341,7 +341,7 @@ value that y will have in joined rows, where it might be NULL rather than
equal to t1.x.
Therefore, Var nodes are decorated with "varnullingrels", which are sets
-of the rangetable indexes of outer joins that potentially null the Var
+of the rangetable indexes that potentially null the Var
at the point where it appears in the query. (Using a set, not an ordered
list, is fine since it doesn't matter which join forced the value to null;
and that avoids having to change the representation when we consider
diff --git a/src/include/nodes/primnodes.h b/src/include/nodes/primnodes.h
index 7d3b4198f26..35b3f881eec 100644
--- a/src/include/nodes/primnodes.h
+++ b/src/include/nodes/primnodes.h
@@ -216,7 +216,7 @@ typedef struct Expr
* row identity information during UPDATE/DELETE/MERGE. This value should
* never be seen outside the planner.
*
- * varnullingrels is the set of RT indexes of outer joins that can force
+ * varnullingrels is the set of Range table entry's indexes that can force
* the Var's value to null (at the point where it appears in the query).
* See optimizer/README for discussion of that.
*
@@ -281,7 +281,7 @@ typedef struct Var
Oid varcollid pg_node_attr(query_jumble_ignore);
/*
- * RT indexes of outer joins that can replace the Var's value with null.
+ * Range table entry's indexes that can replace the Var's value with null.
* We can omit varnullingrels in the query jumble, because it's fully
* determined by varno/varlevelsup plus the Var's query location.
*/
