| From: | Peter Eisentraut <peter(at)eisentraut(dot)org> |
|---|---|
| To: | Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com>, Álvaro Herrera <alvherre(at)kurilemu(dot)de> |
| Cc: | Michael Paquier <michael(at)paquier(dot)xyz>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Quan Zongliang <quanzongliang(at)yeah(dot)net>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Consistently use the XLogRecPtrIsInvalid() macro |
| Date: | 2025-10-30 13:55:51 |
| Message-ID: | d80b6adf-4bfd-4172-a9cd-2ad6e23b1a08@eisentraut.org |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 30.10.25 10:17, Bertrand Drouvot wrote:
> - 0002 deprecates XLogRecPtrIsInvalid(): it emits a warning message at compilation
> time if XLogRecPtrIsInvalid() is in use in the code base.
Surely this could be factored out in macro in such a way that the
warning message is a macro argument and we could reuse this attribute
elsewhere in the code.
That said, I'm suspicious about marking things deprecated before the
replacement is widely available. If an extension has been using
XLogRecPtrIsInvalid() until now (which has been best practice), when
that extension adds PG19 support, they will either have to backport
XLogRecPtrIsValid or turn off deprecation warnings. At least there
should be some guidance about what you expect third-party code to do
about this.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2025-10-30 14:00:05 | pg_plan_advice |
| Previous Message | Tom Lane | 2025-10-30 13:55:42 | Re: abi-compliance-check failure due to recent changes to pg_{clear,restore}_{attribute,relation}_stats() |