From: Tom Lane <tgl@sss.pgh.pa.us>
To: Thomas Munro <thomas.munro@gmail.com>
cc: David Geier <geidav.pg@gmail.com>,
        pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: Consistently use palloc_object() and palloc_array()
In-reply-to: 
 <CA+hUKGK4=dD3qS3Db9d9pWg1me4eoZr1hWSxE_8_NRyKS2gqeA@mail.gmail.com>
References: <ad0748d4-3080-436e-b0bc-ac8f86a3466a@gmail.com>
 <CA+hUKGK4=dD3qS3Db9d9pWg1me4eoZr1hWSxE_8_NRyKS2gqeA@mail.gmail.com>
Comments: In-reply-to Thomas Munro <thomas.munro@gmail.com>
	message dated "Thu, 27 Nov 2025 15:53:20 +1300"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <32294.1764213912.1@sss.pgh.pa.us>
Date: Wed, 26 Nov 2025 22:25:12 -0500
Message-ID: <32295.1764213912@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/32295.1764213912%40sss.pgh.pa.us>
Precedence: bulk

Thomas Munro <thomas.munro@gmail.com> writes:
> This isn't a fully-baked thought, just a thought that occurred to me
> while looking into that:  If palloc_object(Int128AggState) were smart
> enough to detect that alignof(T) > MAXALIGN and redirect to
> palloc_aligned(sizeof(T), alignof(T), ...) at compile time, then
> Int128AggState would naturally propagate the layout requirements of
> its __int128 member, and we wouldn't need to do that weird stuff, and
> it wouldn't be error-prone if usage of __int128 spreads to more
> structs.  That really only makes sense if we generalise
> palloc_object() as a programming style and consider direct use of
> palloc() to be a rarer low-level interface that triggers human
> reviewers to think about alignment, I guess.

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.

			regards, tom lane