aboutsummaryrefslogtreecommitdiff
path: root/src/backend/executor/nodeModifyTable.c
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2025-04-17 12:56:21 -0400
committerTom Lane <tgl@sss.pgh.pa.us>2025-04-17 12:56:21 -0400
commitf45a5444ee7612bcca31172035c9638fed77afcc (patch)
tree6bb2d3899bb85a68911c5f4d391ae8d67e116fde /src/backend/executor/nodeModifyTable.c
parent595d1efeda11186ac6850f5e0bfec877da363e1e (diff)
downloadpostgresql-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