Wrong parent node for WCO expressions in nodeModifyTable.c?

Hi Stephen, All,

While working on the pluggable storage patchset I noticed that it
initializes the WCO expression like:

    /*
     * Initialize any WITH CHECK OPTION constraints if needed.
     */
    resultRelInfo = mtstate->resultRelInfo;
    i = 0;
    foreach(l, node->withCheckOptionLists)
    {
        List       *wcoList = (List *) lfirst(l);
        List       *wcoExprs = NIL;
        ListCell   *ll;

        foreach(ll, wcoList)
        {
            WithCheckOption *wco = (WithCheckOption *) lfirst(ll);
            ExprState  *wcoExpr = ExecInitQual((List *) wco->qual,
                                               mtstate->mt_plans[i]);

            wcoExprs = lappend(wcoExprs, wcoExpr);
        }

        resultRelInfo->ri_WithCheckOptions = wcoList;
        resultRelInfo->ri_WithCheckOptionExprs = wcoExprs;
        resultRelInfo++;
        i++;
    }

note that the parent node for the qual is the plan the tuples originate
from, *not* the target relation. That seems wrong.

It does cause a problem for pluggable storage, but I wonder if it's a
problem beyond that. The fact that the parent is wrong means we'll
anchor subplans within the qual to the wrong parent.  Replacing the
parent with &mtstate->ps itself, there are regression test differences:

 ERROR:  new row violates check option for view "rw_view1"
 DETAIL:  Failing row contains (15).
 EXPLAIN (costs off) INSERT INTO rw_view1 VALUES (5);
-                          QUERY PLAN
----------------------------------------------------------------
+                       QUERY PLAN
+---------------------------------------------------------
  Insert on base_tbl b
    ->  Result
-         SubPlan 1
-           ->  Index Only Scan using ref_tbl_pkey on ref_tbl r
-                 Index Cond: (a = b.a)
-         SubPlan 2
-           ->  Seq Scan on ref_tbl r_1
+   SubPlan 1
+     ->  Index Only Scan using ref_tbl_pkey on ref_tbl r
+           Index Cond: (a = b.a)
+   SubPlan 2
+     ->  Seq Scan on ref_tbl r_1
 (7 rows)

 EXPLAIN (costs off) UPDATE rw_view1 SET a = a + 5;
-                           QUERY PLAN
------------------------------------------------------------------
+                        QUERY PLAN
+-----------------------------------------------------------
  Update on base_tbl b
    ->  Hash Join
          Hash Cond: (b.a = r.a)
          ->  Seq Scan on base_tbl b
          ->  Hash
                ->  Seq Scan on ref_tbl r
-         SubPlan 1
-           ->  Index Only Scan using ref_tbl_pkey on ref_tbl r_1
-                 Index Cond: (a = b.a)
-         SubPlan 2
-           ->  Seq Scan on ref_tbl r_2
+   SubPlan 1
+     ->  Index Only Scan using ref_tbl_pkey on ref_tbl r_1
+           Index Cond: (a = b.a)
+   SubPlan 2
+     ->  Seq Scan on ref_tbl r_2
 (11 rows)

 DROP TABLE base_tbl, ref_tbl CASCADE;

And the new output certainly looks more correct to me.

Stephen, I have not researched this much, but is there a chance this
could cause trouble in the backbranches?

Greetings,

Andres Freund