"Neil Conway" <neilc@samurai.com> writes:
> ... I think better would be to figure out a more appropriate
> memory context to switch into before deleting the multi-call context.
BTW, I did look at that alternative. In principle we could have
init_MultiFuncCall save the current context and let end_MultiFuncCall
switch to that context. However there are a couple of serious problems
with that:
1. There's noplace in FuncCallContext to save it. Adding a field would
represent an ABI break that is certain to break external modules, so
it seems a nonstarter for a back-patchable fix.
2. We can't be absolutely sure that this is the right context to return
to anyway --- perhaps the SRF changed the context before calling
init_MultiFuncCall. (One plausible mechanism for this is if SPI_connect
is called first.) SRF_RETURN_DONE() doesn't give the caller any chance
to fix things afterwards, so a 95% or 99% solution isn't good enough.
In general, I think funcapi.c has no business making a change to the
caller's CurrentMemoryContext in any case. It never did so before the
February patch, and is not documented to do so.
regards, tom lane
