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

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

Previous
From: "Nigel J. Andrews"
Date:
Subject: Re: [HACKERS] [INTERFACES] libpgtcl - backend version information
Next
From: Tom Lane
Date:
Subject: Re: SRF patch (was Re: [HACKERS] troubleshooting pointers)