On 6/12/26 18:10, Peter Geoghegan wrote: > 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. >
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
