Doc: add comment about bug fixed in back branches as of 3f7323cbb.

While the bug I just fixed in the back branches doesn't exist in
HEAD, the requirement that MULTIEXPR SubPlans not share output
parameters still does.  Add a comment to memorialize that, because
perhaps it could be an issue again someday.

Discussion: https://postgr.es/m/17596-c5357f61427a81dc@postgresql.org

diff --git a/src/backend/executor/nodeSubplan.c b/src/backend/executor/nodeSubplan.c
index 43b36dcd3b4f737b38e4b872f640a9a1f8c6c974..434c72c9f206de5e338b2ea8340a1e7a7834d6d1 100644 (file)
--- a/src/backend/executor/nodeSubplan.c
+++ b/src/backend/executor/nodeSubplan.c
@@ -245,6 +245,21 @@ ExecScanSubPlan(SubPlanState *node,
     * ones, so this should be safe.)  Unlike ExecReScanSetParamPlan, we do
     * *not* set bits in the parent plan node's chgParam, because we don't
     * want to cause a rescan of the parent.
+    *
+    * Note: we are also relying on MULTIEXPR SubPlans not sharing any output
+    * parameters with other SubPlans, because if one does then it is unclear
+    * which SubPlanState node the parameter's execPlan field will be pointing
+    * to when we come to evaluate the parameter.  We can allow plain initplan
+    * SubPlans to share output parameters, because it doesn't actually matter
+    * which initplan SubPlan we reference as long as they all point to the
+    * same underlying subplan.  However, that fails to hold for MULTIEXPRs
+    * because they can have non-empty args lists, and the "same" args might
+    * have mutated into different forms in different parts of a plan tree.
+    * There is currently no problem because MULTIEXPR can appear only in an
+    * UPDATE's top-level target list, so it won't get duplicated anyplace.
+    * Postgres versions before v14 had to make concrete efforts to avoid
+    * sharing output parameters across different clones of a MULTIEXPR, and
+    * the problem could recur someday.
     */
    if (subLinkType == MULTIEXPR_SUBLINK)
    {