Improve some comments related to executor result relations.

es_leaf_result_relations doesn't exist; perhaps this was an old name
for es_tuple_routing_result_relations, or maybe this comment has gone
unmaintained through multiple rounds of whacking the code around.

Related comment in execnodes.h was both obsolete and ungrammatical.

diff --git a/src/backend/executor/execMain.c b/src/backend/executor/execMain.c
index 0a766ef1e5adc09b91672818a94b8af8d76546f4..ba156f8c5fcf74e782af15ca3606ee3c12ff35ae 100644 (file)
--- a/src/backend/executor/execMain.c
+++ b/src/backend/executor/execMain.c
@@ -1347,14 +1347,16 @@ InitResultRelInfo(ResultRelInfo *resultRelInfo,
 }
 
 /*
- *             ExecGetTriggerResultRel
- *
- * Get a ResultRelInfo for a trigger target relation.  Most of the time,
- * triggers are fired on one of the result relations of the query, and so
- * we can just return a member of the es_result_relations array, the
- * es_root_result_relations array (if any), or the es_leaf_result_relations
- * list (if any).  (Note: in self-join situations there might be multiple
- * members with the same OID; if so it doesn't matter which one we pick.)
+ * ExecGetTriggerResultRel
+ *             Get a ResultRelInfo for a trigger target relation.
+ *
+ * Most of the time, triggers are fired on one of the result relations of the
+ * query, and so we can just return a member of the es_result_relations array,
+ * or the es_root_result_relations array (if any), or the
+ * es_tuple_routing_result_relations list (if any).  (Note: in self-join
+ * situations there might be multiple members with the same OID; if so it
+ * doesn't matter which one we pick.)
+ *
  * However, it is sometimes necessary to fire triggers on other relations;
  * this happens mainly when an RI update trigger queues additional triggers
  * on other relations, which will be processed in the context of the outer
@@ -1404,6 +1406,7 @@ ExecGetTriggerResultRel(EState *estate, Oid relid)
                if (RelationGetRelid(rInfo->ri_RelationDesc) == relid)
                        return rInfo;
        }
+
        /* Nope, but maybe we already made an extra ResultRelInfo for it */
        foreach(l, estate->es_trig_target_relations)
        {

diff --git a/src/include/nodes/execnodes.h b/src/include/nodes/execnodes.h
index 834708944bf836c0edbd6e180e9bc822dfef75b9..880a03e4e4b7d83555a5a6777e5501a2656ddc55 100644 (file)
--- a/src/include/nodes/execnodes.h
+++ b/src/include/nodes/execnodes.h
@@ -508,11 +508,10 @@ typedef struct EState
        ResultRelInfo *es_result_relation_info; /* currently active array elt */
 
        /*
-        * Info about the target partitioned target table root(s) for
-        * update/delete queries.  They required only to fire any per-statement
-        * triggers defined on the table.  It exists separately from
-        * es_result_relations, because partitioned tables don't appear in the
-        * plan tree for the update/delete cases.
+        * Info about the partition root table(s) for insert/update/delete queries
+        * targeting partitioned tables.  Only leaf partitions are mentioned in
+        * es_result_relations, but we need access to the roots for firing
+        * triggers and for runtime tuple routing.
         */
        ResultRelInfo *es_root_result_relations;        /* array of ResultRelInfos */
        int                     es_num_root_result_relations;   /* length of the array */