Joe Conway <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly