Re: [[deprecated("don't call this, call that")]]

From: Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: [[deprecated("don't call this, call that")]]
Date: 2026-04-09 11:31:20
Message-ID: adeOCJ/hFCpVe6pf@ip-10-97-1-34.eu-west-3.compute.internal
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: 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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bertrand Drouvot 2026-04-09 11:41:39 Re: Make copyObject work in C++
Previous Message Bertrand Drouvot 2026-04-09 11:28:24 Re: Reduce build times of pg_trgm GIN indexes