Ronan Dunklau <rdunklau@gmail.com> writes:
>> I intentionally did the nestloop_params substitution after calling
>> GetForeignPlan not before. It's not apparent to me why it would be
>> useful to do it before, because the FDW is going to have no idea what
>> those params represent. (Note that they represent values coming from
>> some other, probably local, relation; not from the foreign table.)
> Even if the FDW have no idea what they represent, it can identify a
> clause of the form Var Operator Param, which allows to store the param
> reference (paramid) for retrieving the param value at execution time.
I don't see any plausible reason for an FDW to special-case nestloop
params like that. What an FDW should be looking for is clauses of the
form Var-of-foreign-table Operator Expression-not-involving-foreign-table,
and a Param is just one case of Expression-not-involving-foreign-table.
(Compare the handling of indexscan clauses: indxpath.c doesn't much care
what's on the righthand side of an indexable clause, so long as there
is no Var of the indexed table there.)
Moreover, in order to do effective parameterized-path creation in the
first place, the FDW's GetForeignPaths function will already have had
to recognize these same clauses in their original form. If we do the
param substitution before calling GetForeignPlan, that will just mean
that the two functions can't share code anymore.
Or in short: the fact that the righthand-side expression gets replaced
(perhaps only partially) by a Param is an implementation detail of the
executor's expression evaluation methods. The FDW shouldn't care about
that, only about the result of the expression.
regards, tom lane