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

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

From: Joe Conway <mail(at)joeconway(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-patches(at)postgresql(dot)org
Subject: Re: SRF patch (was Re: [HACKERS] troubleshooting pointers)
Date: 2002-05-19 21:40:30
Message-ID: 3CE81BCE.6090805@joeconway.com (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
Tom Lane wrote:
> Joe Conway <mail(at)joeconway(dot)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



In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2002-05-19 22:22:29
Subject: Indexscan API cleanup proposal
Previous:From: Bear GilesDate: 2002-05-19 21:38:51
Subject: Re: pq_eof() broken with SSL

pgsql-patches by date

Next:From: Tom LaneDate: 2002-05-19 22:36:19
Subject: Re: SRF patch (was Re: [HACKERS] troubleshooting pointers)
Previous:From: Tom LaneDate: 2002-05-19 21:27:17
Subject: Re: SRF patch (was Re: [HACKERS] troubleshooting pointers)

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