Re: s/pg_attribute_always_inline/pg_always_inline/?

On 7/10/26 14:34, Tomas Vondra wrote:
> On 7/10/26 02:14, Tom Lane wrote:
>> Tomas Vondra <tomas(at)vondra(dot)me> writes:
>>> Does "backpatching the new macro" mean we'd also adjust all existing
>>> places to use the new macro or not? I mean, we could backpatch just the
>>> bit in c.h. I plan to adjust the places, to minimize possible conflicts
>>> when backpatching other stuff.
>>
>> I think it'd be sufficient to add the new macro to the old branches.
>> The point of back-patching at all, I think, is to save ourselves
>> work if we have to back-patch some new code that uses the new style.
>>
>
> I'm not very worried about new code using the new macro name. We only
> use it in ~50 places, and I don't think fixes will use it very often.
> It's more likely a fix will touching some code nearby, and the
> cherry-pick will fail because of the difference.
>
> I intend to backpatch "everything", with backbranches having both macros
> (as in the -19 patch).
>

FWIW here are the per-version patches what I plan to commit + backpatch.

At some point I was worried we might end up with an awful mix of code
using the two variants of the macro in the backbranches (old removed
code with old naming, and new name in code updated by the backpatch).

But that really does not seem to happen. Essentially the only code stuck
with the old name (pg_atttribute_...) is three lines in tuplesort.c
(which disappeared in 19).

So I think it's fine. I still want to double-check the backpatches.

regards

--
Tomas Vondra