Split some storage out to separate subcontexts of fcontext.
Put the JunkFilter and its result slot (and thence also
some subsidiary data such as the result tupledesc) into a
separate subcontext "jfcontext". This doesn't accomplish
a lot at this point, because we make a new JunkFilter each
time through the SQL function. However, the plan is to make
the fcontext long-lived, and that raises the possibility
that we'll need a new JunkFilter because the plan for the
result-generating query changes. A separate context makes
it easy to free the obsoleted data when that happens.
Also, instead of always running the sub-executor in fcontext,
make a separate context for it if we're doing lazy eval of
a SRF, and otherwise just run it inside CurrentMemoryContext.
Branch
------
master
Details
-------
https://git.postgresql.org/pg/commitdiff/f45a5444ee7612bcca31172035c9638fed77afcc
Modified Files
--------------
src/backend/executor/functions.c | 82 ++++++++++++++++++++++++++++++++--------
1 file changed, 67 insertions(+), 15 deletions(-)
