Subject: s/pg_attribute_always_inline/pg_always_inline/?

From: Andres Freund <[email-masked]>
Date: Wed, 8 Apr 2026 17:09:12 -0400

Hi,

When reviewing the index prefetching patch I got a bit dismayed at how long
pg_attribute_always_inline is due to the way it triggers pgindent to format
stuff.

I propose that we remove the _attribute_ part of the name.

Given that it is implemented for compilers that don't use the
__attribute__((always_inline)) spelling, so the shorter name seems better
anyway.

Thoughts?

Greetings,

Andres Freund

---

From: Peter Geoghegan <[email-masked]>
Date: Wed, 8 Apr 2026 17:30:21 -0400

> pg_attribute_always_inline is due to the way it triggers pgindent to format

I had to significantly reorder function prototypes to avoid overly
long prototypes that had pg_attribute_always_inline. While perhaps not
strictly necessary, we shouldn't have to work around the fact that
pg_attribute_always_inline is an absurdly verbose symbol name.

> I propose that we remove the _attribute_ part of the name.

+1

-- 
Peter Geoghegan

---

From: Peter Eisentraut <[email-masked]>
Date: Thu, 9 Apr 2026 02:00:37 +0200

> __attribute__((always_inline)) spelling, so the shorter name seems better

Yes, and the existing name is also kind of wrong even on GCC because the 
macro does not expand to only an attribute but also includes the "inline".

---

From: Andres Freund <[email-masked]>
Date: Thu, 9 Apr 2026 10:40:30 -0400

Hi,

> macro does not expand to only an attribute but also includes the "inline".

It didn't start out that way, that only came in a bit later, in
434e6e148441...

Created a CF entry, to reduce the chances of me forgetting about committing
this early in the 20 cycle.

Greetings,

Andres Freund

---

From: Peter Geoghegan <[email-masked]>
Date: Wed, 27 May 2026 15:17:20 -0700

> 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 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.

-- 
Peter Geoghegan

---

From: Tomas Vondra <[email-masked]>
Date: Fri, 12 Jun 2026 17:22:58 +0200

> that is both consistent with pg_noinline, and even terser than your

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.

> 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

---

From: Peter Geoghegan <[email-masked]>
Date: Fri, 12 Jun 2026 12:10:39 -0400

> 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

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.

> 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.

-- 
Peter Geoghegan

---

From: Tomas Vondra <[email-masked]>
Date: Wed, 8 Jul 2026 23:41:47 +0200

> 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

---

From: David Rowley <[email-masked]>
Date: Thu, 9 Jul 2026 12:02:03 +1200

> just do that. ISTM the agreement is to backpatch this too.

How about just backpatching the new macro and leaving the old one in
place back branches? There should be slightly less backpatching pain
that way, for us, and fewer merge issues for people maintaining forks
on existing versions.

David

---

From: Tom Lane <[email-masked]>
Date: Wed, 08 Jul 2026 20:14:49 -0400

> place back branches?

+1.  Breaking valid code in released branches is unfriendly.

			regards, tom lane

---

From: Peter Geoghegan <[email-masked]>
Date: Thu, 9 Jul 2026 02:05:48 -0400

> just do that. ISTM the agreement is to backpatch this too.

+1 to backpatching, along with a compatibility macro that supports the
original spelling on backbranches only.

-- 
Peter Geoghegan