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(at)sss(dot)pgh(dot)pa(dot)us>
:21744(dot)1149198794(at)sss(dot)pgh(dot)pa(dot)us(dot)(dot)(dot)
> "Jackie Leng" <lengjianquan(at)163(dot)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
>