Re: SRF patch (was Re: [HACKERS] troubleshooting pointers)
От | Joe Conway |
---|---|
Тема | Re: SRF patch (was Re: [HACKERS] troubleshooting pointers) |
Дата | |
Msg-id | 3CE81BCE.6090805@joeconway.com обсуждение исходный текст |
Ответ на | SRF patch (was Re: [HACKERS] troubleshooting pointers) (Joe Conway <mail@joeconway.com>) |
Ответы |
Re: SRF patch (was Re: [HACKERS] troubleshooting pointers)
|
Список | pgsql-patches |
Tom Lane wrote: > Joe Conway <mail@joeconway.com> writes: > >>Here's a small patch to ExecFunctionReScan. It was clearing >> scanstate->csstate.cstate.cs_ResultTupleSlot >>when I think it should have been clearing >> scanstate->csstate.css_ScanTupleSlot > > > Why do you think that? To the extent that other rescan routines are > clearing anything, they're clearing ResultTupleSlot. Well, nodeMaterial and nodeSort both clear cs_ResultTupleSlot, but they also use cs_ResultTupleSlot in ExecMaterial/ExecSort, whereas FunctionNext uses css_ScanTupleSlot. But as you pointed out, perhaps it's a noop anyway. I was having trouble getting everything to work correctly with FunctionNext using cs_ResultTupleSlot. I guess I don't really understand the distinction, but I did note that the scan nodes (subqueryscan, seqscan, etc) used css_ScanTupleSlot, while the materialization nodes tended to use cs_ResultTupleSlot. Joe
В списке pgsql-patches по дате отправления: