On 12/03/21 20:22, Tom Lane wrote:
> 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
> tuptable
Chapman Flack 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, b
Hi,
When SPI produces a tuple table result, its DestReceiver makes a new
"SPI TupTable" memory context, as a child of the SPI Proc context,
and the received tuples get copied into it. It goes away at SPI_finish,
as a consequence of its parent SPI Proc context going away.
If a person
