Re: Consistently use palloc_object() and palloc_array() - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Consistently use palloc_object() and palloc_array()
Date
Msg-id aTikrhT9NvtKncUK@paquier.xyz
Whole thread Raw
In response to Re: Consistently use palloc_object() and palloc_array()  (Michael Paquier <michael@paquier.xyz>)
Responses Re: Consistently use palloc_object() and palloc_array()
Re: Consistently use palloc_object() and palloc_array()
List pgsql-hackers
On Fri, Dec 05, 2025 at 04:41:41PM +0900, Michael Paquier wrote:
> Thanks.  That's a lot to digest.

Digesting a bit more now..

-   char       *ret = palloc(sizeof(buf));
+   char       *ret = palloc_array(char, sizeof(buf))

This one in dumputils.c is right, but I am not sure that it is an
improvement compared to the statu-quo.

Here is a list of the files where I have noticed tha addition of
casts, which are not required anymore:
brin_tuple.c.
gistbuildbuffers.c.
genam.c.
nbtdedup.c.
nbtree.c.
nbtsort.c.
index.c
execGrouping.c
execMain.c
relnode.c
partbounds.c
mcv.c
spell.c
arrayfuncs.c
partcache.c

Perhaps you have used a semi-automatic process and missed these?
Okay, some of these relied on a "Data" structure for the size vs
pointer for the allocation, but the results are the same.

-       IndexOrderByDistance *distances =
-           palloc(sizeof(distances[0]) * so->numberOfOrderBys);

Okay, this one in spgscan.c is not the usual project style.  Correct,
still funky.

            b_checkargnulls =
-               palloc(sizeof(LLVMBasicBlockRef *) * op->d.func.nargs);
+               palloc_array(LLVMBasicBlockRef *, op->d.func.nargs);

This one in llvmjit_expr.c was causing a compilation failure.  I am
not exactly sure why, but discarded for now.  I got a reproduction
locally as well as in the CI.

-   node->tsm_state = palloc0(sizeof(BernoulliSamplerData));
+   node->tsm_state = palloc0_object(BernoulliSamplerData);

One can argue that this one in bernouilli.c is not really necessary,
tsm_state is actually a void *.

Among the 300-ish files changed in the backend, 48 of them had their
builds slightly change.  The list of them is attached.

So that's everything for the trivial changes, with 4601e7f1c708 for
src/backend/ and 0c3c5c3b06a3 for the rest.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Solaris versus our NLS files
Next
From: Thomas Munro
Date:
Subject: Re: Solaris versus our NLS files