Re: SPI TupTable memory context

Chapman Flack <chap(at)anastigmatix(dot)net> writes:
> If a person wanted to refer to those tuples after SPI_finish,
> would it be a dangerous idea to just reparent that context into one
> that will live longer, shortly before SPI_finish is called?

Seems kinda dangerous to me ...

> AtEOSubXact_SPI can free tuptables retail, but only in the rollback case.

... precisely because of that. If you wanted to take control of
the TupTable, you'd really need to unhook it from the SPI context's
tuptables list, and that *really* seems like undue familiarity
with the implementation.

On the whole this seems like the sort of thing where if it breaks,
nobody is going to have a lot of sympathy. What I'd suggest,
if you don't want to let the SPI mechanisms manage that memory,
is to not put the tuple set into a SPITupleTable in the first
place. Run the query with a different DestReceiver that saves the
query result someplace you want it to be (see SPI_execute_extended
and the options->dest argument).

regards, tom lane