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
