SRF memory mgmt patch (was [HACKERS] Concern about memory management with SRFs)

Tom Lane wrote:
> Joe Conway <mail(at)joeconway(dot)com> writes:
>>Is it OK to use fcinfo->flinfo->fn_mcxt as the long term memory
>>context or is there a better choice?
>
> That is the correct choice.
>
>>Is funcctx->multi_call_memory_ctx a
>>suitable name in place of funcctx->fmctx?
>
> No objection here.

Here's a patch to address Tom's SRF API memory management concerns, as
discussed earlier today on HACKERS.

Please note that, although this should apply cleanly on cvs tip, it will
have (two) failed hunks (nodeFunctionscan.c) *if* applied after Neil's
plpgsql SRF patch. Or it will cause a failure in Neil's patch if it is
applied first (I think). The fix in either case is to wrap the loop that
collects rows from the function and stashes them in the tuplestore as
follows:

do until no more tuples
+ ExprContext *econtext = scanstate->csstate.cstate.cs_ExprContext;

get one tuple
put it in the tuplestore

+ ResetExprContext(econtext);
loop

Also note that contrib/dblink is intentionally missing, because I'm
still working on other aspects of it. I'll have an updated dblink in a
day or so.

If there are no objections, please apply.

Thanks,

Joe