| 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
| 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 |