Re: s/pg_attribute_always_inline/pg_always_inline/?

On 6/12/26 18:10, Peter Geoghegan wrote:
> On Fri, Jun 12, 2026 at 11:23 AM Tomas Vondra <tomas(at)vondra(dot)me> wrote:
>> 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'm not going to make a fuss about it.
>
>> Yeah, we should not do such weird stuff just because of unnecessarily
>> long attribute names.
>
> Right. Basically, I don't want to be told that I must completely
> change the order of function definitions because I used
> pg_[attribute]_always_inline. It's just not reasonable to impose that
> requirement on patch authors.
>
>> 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.
>
> I think that we should bite the bullet and backpatch. I count only 17
> instances of pg_attribute_always_inline on the master branch.
>
> Some extensions will no longer build against the backbranches if we go
> this way. However, extension authors should find it easy to work
> around this on an ad-hoc basis. They're going to have to work around
> it sooner or later, so we might as well favor the new spelling.
>

So, what shall we do about this? I've been looking at the v29 of the
index prefetching patch series, which is using this attribute in a bunch
of places. And that reminded me of this thread.

I guess we should just commit that, so unless someone objects soon I'll
just do that. ISTM the agreement is to backpatch this too.

regards

--
Tomas Vondra