Ronan Dunklau <rdunk...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers