On Fri, Jun 12, 2026 at 11:23 AM Tomas Vondra <tomas@vondra.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.
--
Peter Geoghegan
