Re: retire MemoryContextResetAndDeleteChildren backwards compatibility macro

Alvaro Herrera <alvherre@alvh.no-ip.org>

From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: Nathan Bossart <nathandbossart@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Dagfinn Ilmari Mannsåker <ilmari@ilmari.org>, pgsql-hackers@postgresql.org
Date: 2023-11-14T19:20:08Z
Lists: pgsql-hackers
On 2023-Nov-14, Nathan Bossart wrote:

> On Tue, Nov 14, 2023 at 12:10:41PM -0500, Tom Lane wrote:
> > FWIW, I think it's fine to just nuke MemoryContextResetAndDeleteChildren.
> > We ask extension authors to deal with much more significant API changes
> > than that in every release, and versions where the updated code wouldn't
> > work are long gone.  And, as you say, the existence of that separate from
> > MemoryContextReset creates confusion, which has nonzero cost in itself.
> 
> That is my preference as well.  Alvaro, AFAICT you are the only vote
> against removing it completely.  If you feel ѕtrongly about it,

Oh, I don't.  (But I wouldn't mind putting pg_attribute_deprecated to
good use elsewhere ... not that I have any specific examples handy.)

Your S key seems to be doing some funny business.

-- 
Álvaro Herrera               48°01'N 7°57'E  —  https://www.EnterpriseDB.com/
"Hay dos momentos en la vida de un hombre en los que no debería
especular: cuando puede permitírselo y cuando no puede" (Mark Twain)



Commits

  1. Retire MemoryContextResetAndDeleteChildren() macro.

  2. Simplify code by getting rid of SPI_push, SPI_pop, SPI_restore_connection.

  3. Redefine MemoryContextReset() as deleting, not resetting, child contexts.

  4. tuplestore_donestoring() isn't needed anymore, but provide a no-op