Tom Lane wrote:
> I am still concerned about whether ExecFunctionReScan works correctly;
> if not, the problems would show up in join and subquery situations.
> I think the parser and planner stages are in pretty good shape now,
> though. (At least as far as the basic functionality goes. Having
> a smarter materialization policy will take work in the planner.)
>
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
although there is no discernable (at least to me) difference either way.
Joe
Index: src/backend/executor/nodeFunctionscan.c
===================================================================
RCS file: /opt/src/cvs/pgsql/src/backend/executor/nodeFunctionscan.c,v
retrieving revision 1.1
diff -c -r1.1 nodeFunctionscan.c
*** src/backend/executor/nodeFunctionscan.c 12 May 2002 20:10:02 -0000 1.1
--- src/backend/executor/nodeFunctionscan.c 19 May 2002 20:11:10 -0000
***************
*** 370,389 ****
void
ExecFunctionReScan(FunctionScan *node, ExprContext *exprCtxt, Plan *parent)
{
! FunctionScanState *scanstate;
!
! /*
! * get information from node
! */
! scanstate = (FunctionScanState *) node->scan.scanstate;
!
! ExecClearTuple(scanstate->csstate.cstate.cs_ResultTupleSlot);
/*
* If we haven't materialized yet, just return.
*/
if (!scanstate->tuplestorestate)
return;
/*
* Here we have a choice whether to drop the tuplestore (and recompute
--- 370,384 ----
void
ExecFunctionReScan(FunctionScan *node, ExprContext *exprCtxt, Plan *parent)
{
! FunctionScanState *scanstate = (FunctionScanState *) node->scan.scanstate;
/*
* If we haven't materialized yet, just return.
*/
if (!scanstate->tuplestorestate)
return;
+
+ ExecClearTuple(scanstate->csstate.css_ScanTupleSlot);
/*
* Here we have a choice whether to drop the tuplestore (and recompute