Re: s/pg_attribute_always_inline/pg_always_inline/?

From: Tomas Vondra <tomas(at)vondra(dot)me>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, David Rowley <dgrowleyml(at)gmail(dot)com>
Cc: Peter Geoghegan <pg(at)bowt(dot)ie>, Andres Freund <andres(at)anarazel(dot)de>, Peter Eisentraut <peter(at)eisentraut(dot)org>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: s/pg_attribute_always_inline/pg_always_inline/?
Date: 2026-07-10 00:05:43
Message-ID: 3184af6f-75a2-4b43-8223-897b71970fef@vondra.me
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 7/9/26 02:14, Tom Lane wrote:
> David Rowley <dgrowleyml(at)gmail(dot)com> writes:
>> On Thu, 9 Jul 2026 at 09:42, Tomas Vondra <tomas(at)vondra(dot)me> wrote:
>>> 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.
>
>> How about just backpatching the new macro and leaving the old one in
>> place back branches?
>
> +1. Breaking valid code in released branches is unfriendly.
>

OK, that sounds reasonable. So in the backbranches we'd have both
pg_always_inline and the original pg_attriute_always_inline.

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.

regards

--
Tomas Vondra

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alberto Piai 2026-07-10 00:10:57 Re: Adding a stored generated column without long-lived locks
Previous Message Fujii Masao 2026-07-09 23:42:34 Re: Truncate logs by max_log_size