Subject: Re: Do away with a few backwards compatibility macros

From: Nathan Bossart <[email-masked]>
Date: Thu, 16 Nov 2023 09:46:22 -0600

On Thu, Nov 16, 2023 at 07:11:41PM +0530, Bharath Rupireddy wrote:
> After a recent commit 6a72c42f (a related discussion [1]) which
> removed MemoryContextResetAndDeleteChildren(), I think there are a
> couple of other backward compatibility macros out there that can be
> removed. These macros are tuplestore_donestoring() which was
> introduced by commit dd04e95 21 years ago and SPI_push() and friends
> which were made no-ops macros by commit 1833f1a 7 years ago. Debian
> code search shows very minimal usages of these macros. Here's a patch
> attached to remove them.

I'm fine with this because all of these macros are no-ops for all supported
versions of Postgres.  Even if an extension is using them today, you'll get
the same behavior as before if you remove the uses and rebuild against
v12-v16.

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

---

From: Nathan Bossart <[email-masked]>
Date: Mon, 20 Nov 2023 22:58:40 -0600

> the same behavior as before if you remove the uses and rebuild against

Barring objections, I'll plan on committing this in the next week or so.

---

From: Tom Lane <[email-masked]>
Date: Tue, 21 Nov 2023 00:05:36 -0500

> Barring objections, I'll plan on committing this in the next week or so.

No objection here, but should we try to establish some sort of project
policy around this sort of change (ie, removal of backwards-compatibility
support)?  "Once it no longer matters for any supported version" sounds
about right to me, but maybe somebody has an argument for thinking about
it differently.

			regards, tom lane

---

From: Nathan Bossart <[email-masked]>
Date: Tue, 21 Nov 2023 09:52:03 -0600

> about right to me, but maybe somebody has an argument for thinking about

That seems reasonable to me.  I don't think we need to mandate that
backwards-compatibility support be removed as soon as it is eligible, but
it can be considered fair game at that point.

---

From: Bharath Rupireddy <[email-masked]>
Date: Mon, 27 Nov 2023 16:29:18 +0530

> it can be considered fair game at that point.

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.

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

--
Bharath Rupireddy
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com

---

From: Nathan Bossart <[email-masked]>
Date: Mon, 27 Nov 2023 13:14:39 -0600

> -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.