Re: [PATCHES] SRF patch (was Re: troubleshooting pointers)
От | Tom Lane |
---|---|
Тема | Re: [PATCHES] SRF patch (was Re: troubleshooting pointers) |
Дата | |
Msg-id | 11170.1021843354@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [PATCHES] SRF patch (was Re: troubleshooting pointers) (Joe Conway <mail@joeconway.com>) |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: