Re: s/pg_attribute_always_inline/pg_always_inline/? - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: s/pg_attribute_always_inline/pg_always_inline/?
Date
Msg-id CAH2-Wzks_t1QrkZn=hNMsraaUSYfOE15d2Ra1QkMWr9H77hVgQ@mail.gmail.com
Whole thread
In response to Re: s/pg_attribute_always_inline/pg_always_inline/?  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
On Fri, Jul 10, 2026 at 1:32 PM Andres Freund <andres@anarazel.de> wrote:
> Same. Personally I'd not have adjusted the uses of the macro in the
> backbranches, but I don't have a problem with you doing that either.

FWIW a quick Debian code search shows the following Debian packages
depend on the current pg_attribute_always_inline spelling (excluding
Postgres itself):

pg-stat-plans, documentdb, timescaledb, mobilitydb, libpg-query, postgresql-rum

libpg-query and mobilitydb don't really count, because they seem to
vendor src/postgres/include/c.h directly. postgresql-rum and
pg-stat-plans definitely use pg_attribute_always_inline as
straightforward extensions. I think that the rest are also simple
extensions that rely on the authoritative pg_attribute_always_inline,
but I didn't check.

--
Peter Geoghegan



pgsql-hackers by date:

Previous
From: Haibo Yan
Date:
Subject: Re: implement CAST(expr AS type FORMAT 'template')
Next
From: "Matheus Alcantara"
Date:
Subject: Re: Show expression of virtual columns in error messages