| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | David Geier <geidav(dot)pg(at)gmail(dot)com> |
| Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Consistently use palloc_object() and palloc_array() |
| Date: | 2025-11-27 00:24:20 |
| Message-ID: | aSeaNNJqIzQTd3LI@paquier.xyz |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, Nov 26, 2025 at 11:09:31PM +0100, David Geier wrote:
> I've changed all code to use the "new" palloc_object(), palloc_array(),
> palloc0_object(), palloc0_array, repalloc_array() and repalloc0_array()
> macros. This makes the code more readable and more consistent.
>
> The patch is pretty big but potential merge conflicts should be easy to
> resolve. If preferred, I can also further split up the patch, e.g.
> directory by directory or high impact files first.
The backpatching extra-pain argument indeed comes into mind first when
it comes to such changes, but perhaps we should just bite the bullet
and encourage the new allocation styles across the tree, as you are
doing here. I'm not completely sure if it would make sense to split
things up, if we do I would do it on a subdirectory basis like to
suggest, perhaps, like contrib/, src/backend/executor/, etc. to
balance the blast damage. Did you use some kind of automation to find
all of these? If yes, what did you use?
> The patch is passing "meson test" and I've additionally wrote a script
> that parses the patch file and verifies that every two corresponding +
> and - lines match (e.g. palloc0() replaced by palloc0_array() or
> palloc0_object(), the same for palloc() and repalloc(), additionally
> some checks to make sure the conversion to the _array() variant is
> correct).
It may be an idea to share that as well, so as your checks could be
replicated rather than partially re-guessed.
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2025-11-27 00:35:43 | Re: [PATCH] Add native PIVOT syntax for SQL Server/Oracle compatibility |
| Previous Message | Michael Paquier | 2025-11-26 23:34:50 | Re: Add pg_buffercache_mark_dirty[_all] functions to the pg_buffercache |