Split some storage out to separate subcontexts of fcontext.
authorTom Lane <tgl@sss.pgh.pa.us>
Thu, 17 Apr 2025 16:56:21 +0000 (12:56 -0400)
committerTom Lane <tgl@sss.pgh.pa.us>
Thu, 17 Apr 2025 16:56:21 +0000 (12:56 -0400)
commitf45a5444ee7612bcca31172035c9638fed77afcc
tree6bb2d3899bb85a68911c5f4d391ae8d67e116fde
parent595d1efeda11186ac6850f5e0bfec877da363e1e
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.
src/backend/executor/functions.c