Joe Conway <mail@joeconway.com> writes:
> Any ideas on getting (node->scan.plan.chgParam != NULL) to be true?
You need something that passes a parameter into the scan node.
I think the only thing that would do it is a subquery that references
an outer-level variable, for example
select * from foo where fooid in
(select barid from bar(foo.fieldx));
Here, each time we rescan the subselect result for a new foo row, we
need to update the foo.fieldx Param to the new value for the new row.
That's what the chgParam mechanism is for: to notify you that a Param
changed since your last scan. (Without that, you could and probably
should just rewind and regurgitate your prior output.)
Note that
select * from foo, bar(5000) where fooid = barid
does not involve any parameters: the WHERE condition will be executed
by the join node, and the FunctionScan node will have no contact at all
with data coming from the other table.
Now that I think about it, it's possible that ExecFunctionReScan is
correct now, at least given the simplistic always-materialize policy
that we've implemented so far. But it hasn't gotten much testing.
regards, tom lane
