Re: s/pg_attribute_always_inline/pg_always_inline/?

On 5/28/26 00:17, Peter Geoghegan wrote:
> On Thu, Apr 9, 2026 at 10:40 AM Andres Freund <andres(at)anarazel(dot)de> 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