Re: [[deprecated("don't call this, call that")]] - Mailing list pgsql-hackers

From Bertrand Drouvot
Subject Re: [[deprecated("don't call this, call that")]]
Date
Msg-id adeOCJ/hFCpVe6pf@ip-10-97-1-34.eu-west-3.compute.internal
Whole thread Raw
In response to Re: [[deprecated("don't call this, call that")]]  (Michael Paquier <michael@paquier.xyz>)
List pgsql-hackers
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



pgsql-hackers by date:

Previous
From: Bertrand Drouvot
Date:
Subject: Re: Reduce build times of pg_trgm GIN indexes
Next
From: Bertrand Drouvot
Date:
Subject: Re: Make copyObject work in C++