Date: Thu, 9 Apr 2026 11:31:20 +0000
From: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
To: Michael Paquier <michael@paquier.xyz>
Cc: Thomas Munro <thomas.munro@gmail.com>,
	PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: [[deprecated("don't call this, call that")]]
Message-ID: <adeOCJ/hFCpVe6pf@ip-10-97-1-34.eu-west-3.compute.internal>
References: 
 <CA+hUKGK2zuRevnNzCpVzLA7ieHnJoYPnDvgtWRcB4pVnOzchhQ@mail.gmail.com>
 <adcgLAKdTwBeYbjM@paquier.xyz>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <adcgLAKdTwBeYbjM@paquier.xyz>
Archived-At: 
 <https://www.postgresql.org/message-id/adeOCJ/hFCpVe6pf%40ip-10-97-1-34.eu-west-3.compute.internal>
Precedence: bulk

Hi,

On Thu, Apr 09, 2026 at 12:42:36PM +0900, Michael Paquier wrote:
> On Thu, Apr 09, 2026 at 03:34:30PM +1200, Thomas Munro wrote:
> > The idea would be to back-patch the deprecation warnings, and delete
> > the functions in, I guess now, v20.  Then the deprecation notice
> > facility would always be there for next time we need it.
> 
> That would be a nice addition, especially with the recent mblen()
> business (could have used that a few times myself).  So +1 for the
> addition of the macro in the back branches.
> 
> Do we need to be that conservative with the removal in v19?  We could
> just pull the deletion switch without waiting for v20, IMO..  With the
> deprecated macro in place, at least folks would be aware of the
> problem.

+1 on the idea. FWIW it has also been proposed in [1]. Also good candidates are
XLogRecPtrIsInvalid() and StaticAssertStmt(). Note that a recent commit made
use of StaticAssertStmt(), see [2].

[1]: https://postgr.es/m/aRGa87Ab0f3ItWRV@ip-10-97-1-34.eu-west-3.compute.internal
[2]: https://postgr.es/m/adeNWH5pDawDvvR2%40ip-10-97-1-34.eu-west-3.compute.internal

Regards,

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