Re: Consistently use palloc_object() and palloc_array()

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: David Geier <geidav(dot)pg(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Consistently use palloc_object() and palloc_array()
Date: 2025-12-10 23:01:49
Message-ID: aTn73SDlm922r67G@paquier.xyz
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Dec 10, 2025 at 12:48:35PM +0100, David Geier wrote:
> On 09.12.2025 23:37, Michael Paquier wrote:
>> On Fri, Dec 05, 2025 at 04:41:41PM +0900, Michael Paquier wrote:
> Do you mean in these files I forgot removing casts that got unnecessary
> after using _array() / _object()? It's possible that I missed some,
> given the large amount. Please fix them as you see fit.

Yes, your patch did not remove casts in all the files I have listed
upthread. I have fixed them already in the tree, for all the trivial
changes.

>> One can argue that this one in bernouilli.c is not really necessary,
>> tsm_state is actually a void *.
>
> As stated above: this change is not only about saving casts but the
> macros convey the intent much better than a call to palloc().

I got that, but I could not convinced myself that such cases are worth
it. We don't have many of them in the tree anyway. They count for
less than 1% of all the changes dealt with here

>> Among the 300-ish files changed in the backend, 48 of them had their
>> builds slightly change. The list of them is attached.
>
> Do you mean the disassembly because the number of lines of code changes?

Yes, I have cross-checked the reports generated between before and
after the patches, to see that they matched with the formulas
changing. A trick that I have used here and that was rather painful
is to manually change the files where the formulas got shorter to make
their build match.. But well..

I still need to get through the remaining dubious changes you have
posted, including the llvm one that was wrong. It seems like some of
these things warrant a backpatch.
--
Michael

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Chao Li 2025-12-10 23:28:13 Re: Propose: Adding a '--enable-failover' option to 'pg_createsubscriber'
Previous Message Jelte Fennema-Nio 2025-12-10 23:01:15 Re: Proposal to allow setting cursor options on Portals