On Fri, Jun 12, 2026 at 11:23 AM Tomas Vondra <[email protected]> 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
