Re: SPI TupTable memory context

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
> tuptables list, and that *really* seems like undue familiarity
> with the implementation.

Fair enough. I didn't have an immediate use in mind, but had been reading
through DestReceiver code and noticed it worked that way, and that it
looked as if an SPI_keeptuptable could have been implemented in probably
no more than the 25 lines of SPI_keepplan, and I wasn't sure if that was
because it had been considered and deemed a Bad Thing, or because the idea
hadn't come up.

The equivalent with a custom DestReceiver would certainly work, but with
a lot more ceremony.

So that was why I asked. If the response had been more like "hmm, no clear
reason a patch to do that would be bad", and if such a patch got accepted
for PG release n, that could also implicitly assuage worries about undue
familiarity for implementing the compatible behavior when building on < n.

Regards,
-Chap