| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, David Geier <geidav(dot)pg(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Consistently use palloc_object() and palloc_array() |
| Date: | 2025-11-27 05:18:29 |
| Message-ID: | aSffJWtqfi0ut6NI@paquier.xyz |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, Nov 26, 2025 at 10:25:12PM -0500, Tom Lane wrote:
> Hmm ... I had the same doubts as Michael about whether this change
> could possibly be worth the ensuing back-patching pain. But if
> it leads to an improvement in type-safety, that'd be a reason to
> take on the work.
Yeah, that sounds like a reason convincing enough to do the jump. I
didn't really feel strongly against the original proposal to begin
with as it improves the code style, FWIW.
The backpatching bits like these are always annoying, of course. Now,
these fancy palloc() routines exist since v16 so that would just mean
two years and two branches that would need special handling. Even
better, why not just backpatch into v15 and v14 the macros in palloc.h
and fe_memutils.h to avoid backpatch hazards due to some new code?
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Shlok Kyal | 2025-11-27 05:38:00 | Re: How can end users know the cause of LR slot sync delays? |
| Previous Message | Fujii Masao | 2025-11-27 05:17:15 | Re: Allow GUC settings in CREATE SUBSCRIPTION CONNECTION to take effect |