diff options
author | Tom Lane <tgl@sss.pgh.pa.us> | 2025-04-17 12:56:21 -0400 |
---|---|---|
committer | Tom Lane <tgl@sss.pgh.pa.us> | 2025-04-17 12:56:21 -0400 |
commit | f45a5444ee7612bcca31172035c9638fed77afcc (patch) | |
tree | 6bb2d3899bb85a68911c5f4d391ae8d67e116fde /src/backend/executor/nodeModifyTable.c | |
parent | 595d1efeda11186ac6850f5e0bfec877da363e1e (diff) | |
download | postgresql-f45a5444ee7612bcca31172035c9638fed77afcc.tar.gz postgresql-f45a5444ee7612bcca31172035c9638fed77afcc.zip |
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.
Diffstat (limited to 'src/backend/executor/nodeModifyTable.c')
0 files changed, 0 insertions, 0 deletions