Skip site navigation (1) Skip section navigation (2)

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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Joe Conway <mail(at)joeconway(dot)com>
Cc: pgsql-patches(at)postgresql(dot)org
Subject: Re: SRF patch (was Re: [HACKERS] troubleshooting pointers)
Date: 2002-05-19 22:36:19
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackerspgsql-patches
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

			regards, tom lane

In response to

pgsql-hackers by date

Next:From: Tom LaneDate: 2002-05-19 22:39:49
Subject: Re: Exposed function to find table in schema search list?
Previous:From: Tom LaneDate: 2002-05-19 22:22:29
Subject: Indexscan API cleanup proposal

pgsql-patches by date

Next:From: Joe ConwayDate: 2002-05-19 23:33:53
Subject: SRF rescan testing
Previous:From: Joe ConwayDate: 2002-05-19 21:40:30
Subject: Re: SRF patch (was Re: [HACKERS] troubleshooting pointers)

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group