Re: SRF patch (was Re: [HACKERS] troubleshooting pointers) - Mailing list pgsql-patches

From Tom Lane
Subject Re: SRF patch (was Re: [HACKERS] troubleshooting pointers)
Date
Msg-id 11519.1021847779@sss.pgh.pa.us
Whole thread Raw
In response to Re: SRF patch (was Re: [HACKERS] troubleshooting pointers)  (Joe Conway <mail@joeconway.com>)
List pgsql-patches
Joe Conway <mail@joeconway.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

pgsql-patches by date:

Previous
From: Joe Conway
Date:
Subject: Re: SRF patch (was Re: [HACKERS] troubleshooting pointers)
Next
From: Bear Giles
Date:
Subject: revised SSL patches