Horton

Re: Do away with a few backwards compatibility macros

Nathan Bossart <nathandbossart@gmail.com>

View thread View on postgr.es
From: Nathan Bossart <nathandbossart@gmail.com>
To: Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2023-11-27T19:14:39Z
Lists: pgsql-hackers 
On Mon, Nov 27, 2023 at 04:29:18PM +0530, Bharath Rupireddy wrote:
> I think it's easy to miss/enforce a documented policy. IMV, moving
> towards pg_attribute_deprecated as Alvaro Herrera said in the other
> thread https://www.postgresql.org/message-id/202311141920.edtj56saukiv%40alvherre.pgsql
> can help. Authors then can declare the variables and functions as
> deprecated so that the code compilation with
> -Wno-deprecated-declarations can help track all such deprecated code.

I'm +1 for adding pg_attribute_deprecated once we have something to use it
for.

> Having said that, I'm all +1 if the v1 patch proposed in this thread gets in.

Committed.

-- 
Nathan Bossart
Amazon Web Services: https://aws.amazon.com

Commits

  1. Retire a few backwards compatibility macros.

  2. Retire MemoryContextResetAndDeleteChildren() macro.

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

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