Re: possible memory leak with SRFs - Mailing list pgsql-hackers

From Tom Lane
Subject Re: possible memory leak with SRFs
Date
Msg-id 8992.1273335136@sss.pgh.pa.us
Whole thread Raw
In response to Re: possible memory leak with SRFs  (Joe Conway <mail@joeconway.com>)
Responses Re: possible memory leak with SRFs
List pgsql-hackers
Joe Conway <mail@joeconway.com> writes:
> I think this is an example of why we still need to implement a real
> SFRM_ValuePerCall mode that allows results to be pipelined. Yes,
> ValuePerCall sort of works from the targetlist, but it is pretty much
> useless for the use cases where people really want to use it.

> Or would a FROM clause ValuePerCall suffer the same issue?

I don't think it'd be a big problem.  We could use the technique
suggested in the comments in ExecMakeTableFunctionResult: use a separate
memory context for evaluating the arguments than for evaluating the
function itself.  This will work in FROM because we can insist the SRF
be at top level.  The problem with SRFs in tlists is that they can be
anywhere and there can be more than one, so it's too hard to keep track
of what to reset when.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Joe Conway
Date:
Subject: Re: possible memory leak with SRFs
Next
From: Joe Conway
Date:
Subject: Re: possible memory leak with SRFs