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
do until no more tuples
+ ExprContext *econtext = scanstate->csstate.cstate.cs_ExprContext;
get one tuple
put it in the tuplestore
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.
In response to
pgsql-hackers by date
|Next:||From: Mario Weilguni||Date: 2002-08-29 06:57:06|
|Subject: Re: C vs. C++ contributions|
|Previous:||From: Tom Lane||Date: 2002-08-29 05:34:01|
|Subject: Re: [SQL] LIMIT 1 FOR UPDATE or FOR UPDATE LIMIT 1? |
pgsql-patches by date
|Next:||From: Neil Conway||Date: 2002-08-29 07:26:25|
|Subject: Re: revised patch for PL/PgSQL table functions|
|Previous:||From: Tom Lane||Date: 2002-08-29 05:22:14|
|Subject: Re: small mistakes in func.sgml |