Re: Increase repalloc_array() usage in buffile.c

On Sat, Aug 08, 2026 at 05:19:59AM +0000, Tristan Partin wrote:
> Here are 3 patches that hope to modernize most vanilla palloc() calls
> where appropriate.

That took some time to go through. Some portions of the patch did not
apply due to some.. cough.. Recent commits. Please feel free to check
the tree around src/pl/ for example.

- arrayKeyData = (ScanKey) palloc(numArrayKeyData * sizeof(ScanKeyData));
+ arrayKeyData = (ScanKey) palloc_array(ScanKeyData, numArrayKeyData);
[...]
- first_sub_key = (ScanKey)
- palloc(list_length(rc->opnos) * sizeof(ScanKeyData));
+ first_sub_key = (ScanKey) palloc_array(ScanKeyData, list_length(rc->opnos));
[...]
- setopstate->sortKeys = (SortSupport)
- palloc0(nkeys * sizeof(SortSupportData));
+ setopstate->sortKeys = (SortSupport) palloc0_array(SortSupportData, nkeys);
[...]
- clauses = (MergeJoinClause) palloc0(nClauses * sizeof(MergeJoinClauseData));
+ clauses = (MergeJoinClause) palloc0_array(MergeJoinClauseData, nClauses);

No need for casts in these ones.

- winobj->notnull_info[argno] = palloc0(newsize);
+ winobj->notnull_info[argno] = palloc0_array(uint8, newsize);
[...]
- repalloc0(winobj->notnull_info[argno], oldsize, newsize);
+ repalloc0_array(winobj->notnull_info[argno], uint8, oldsize, newsize);

Not sure if these are worth changing.

- argv = (char **) palloc0_array(char *, row->nfields);
+ argv = palloc0_array(char *, row->nfields);

In pl_gram.y. Cast that was indeed not required.

There are quite a few places where we assume a number of bytes while
the code enforces char, for code paths where sizeof(char) is not used.
I am having cold feet on these ones as it hides some of the original
intention of the code (noted 50~55 changes or so related to this
pattern). Something similar can be said with pgcrypto, as well. So I
have left these off. The other changes refer generally to more
complex structures.

And 51c43a5dbd86 it is. This kind of work is incremental, and we have
many much more things that could be done. Patches are always welcome,
of course.
--
Michael