Re: pgsql: Fix calculation of plan node extParams to account for the

Yes, finalize_plan really has a bms_intersect, but it's used to compute
"plan->extParam":

 /* Now we have all the paramids */

 if (!bms_is_subset(context.paramids, valid_params))
  elog(ERROR, "plan should not reference subplan's variable");

 plan->extParam = bms_intersect(context.paramids, outer_params);
 plan->allParam = context.paramids;


But what I means is that when we compute "context.paramids", we can filter
out those params refering to a sibling initPlan through bms_intersect, just
like the process to subplan in "finalize_primnode". So, we can change the
following code in finalize_plan. I think it's equivalent to your methods:

  case T_SubqueryScan:

   /*
    * In a SubqueryScan, SS_finalize_plan has already been run on the
    * subplan by the inner invocation of subquery_planner, so there's
    * no need to do it again. Instead, just pull out the subplan's
    * extParams list, which represents the params it needs from my
    * level and higher levels.
    */
   context.paramids = bms_add_members(context.paramids,
     bms_intersect(((SubqueryScan *) plan)->subplan->extParam,
outer_params)); << this line was changed >>
   break;

Am I right?
Thank you! :)


"Tom Lane" <tgl@sss.pgh.pa.us> д����Ϣ����
:21744.1149198794@sss.pgh.pa.us...
> "Jackie Leng" <lengjianquan@163.com> writes:
> > So, my question is why not just add a bms_intersect in the second
occasion
> > just like the first one? Do we need to change so much?
>
> finalize_plan already has a bms_intersect, but it's further down in the
> routine (to share code instead of duplicating it in each of the switch
> cases) --- in CVS HEAD, line 1199.  This is not relevant to the patch
> AFAICS.
>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 9: In versions below 8.0, the planner will ignore your desire to
>        choose an index scan if your joining column's datatypes do not
>        match
>