Re: SRF patch (was Re: [HACKERS] troubleshooting pointers)

Joe Conway <mail(at)joeconway(dot)com> writes:
> 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.

ResultTupleSlot is generally used by plan nodes that do ExecProject;
it holds the tuple formed by ExecProject (ie, the calculated SELECT
targetlist). ScanTupleSlot is normally the raw input tuple. For
Functionscan I'd suppose that the scan tuple is the tuple returned
by the function and ResultTupleSlot holds the result of ExecProject.
To see the difference, consider

SELECT a, b, c+1 FROM foo(33);

where foo returns a tuple (a,b,c,d,e). The scanned tuple is
(a,b,c,d,e), the projected tuple is (a,b,c+1).

It may well be that rescan could usefully clear both scan and result
tuples, but I don't see the point of making such a change only in
FunctionScan.

regards, tom lane