Re: possible memory leak with SRFs

Joe Conway <mail(at)joeconway(dot)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