On 5/28/26 00:17, Peter Geoghegan wrote: > On Thu, Apr 9, 2026 at 10:40 AM Andres Freund <[email protected]> wrote: >> Created a CF entry, to reduce the chances of me forgetting about committing >> this early in the 20 cycle. > > We already have a pg_noinline. How about renaming > pg_attribute_always_inline to pg_mustinline? That is an alternative > that is both consistent with pg_noinline, and even terser than your > proposal. >
I agree we should shorten pg_attribute_always_inline, it's way too verbose. And other attributes don't include the _attribute_ either (like the pg_noinline mentioned here). I'm not sure about pg_mustinline. It seems weird to me, and I'm not sure saving the 3 characters is worth it, pg_always_inline seems better. > I have no intention of holding this patch up with bikeshedding. But I > noticed that even your proposed pg_always_inline rename still leaves > function prototypes over the column limit with moderately verbose > function names. It seems better to avoid that outcome. > Yeah, we should not do such weird stuff just because of unnecessarily long attribute names. Question - do we plan to do this in master only, or was the plan to backpatch the change? I'm not sure if these labels are used outside the core code, that might be an issue for backpatching. regards -- Tomas Vondra
