MIME-Version: 1.0
References: <289125.1770913057@sss.pgh.pa.us>
In-Reply-To: <289125.1770913057@sss.pgh.pa.us>
From: Zsolt Parragi <zsolt.parragi@percona.com>
Date: Fri, 13 Feb 2026 09:58:42 +0000
Message-ID: <CAN4CZFMLn7MqzAqy7uLX7fhAXQ9FUr4E2S0qbpbsvQZM83Pr5Q@mail.gmail.com>
Subject: Re: Our ABI diff infrastructure ignores enum SysCacheIdentifier
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-hackers@lists.postgresql.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://www.postgresql.org/message-id/CAN4CZFMLn7MqzAqy7uLX7fhAXQ9FUr4E2S0qbpbsvQZM83Pr5Q%40mail.gmail.com>
Precedence: bulk

While it isn't strictly ABI, this made me wonder about the static
inline functions in public headers. Wouldn't extensions using those,
compiled with older minor versions have similar issues as issues
caused by actual ABI incompatibility?

I did a quick test with scripts about this in the REL 17 branch, and
there are several changes that could cause issues in theory.

See ffd9b8134658 for example introduced in 17.3. While technically
this is ABI compatible (nbanks is the same size as bank_mask in the
public struct, no binary change), part of the modified calculation is
in an inline function in the header, but part of it is in the C part.
Extensions compiled against 17.2 or earlier and using this
functionality will misbehave in 17.3 or later, as only part of the
code gets updated.

Similar issues could be caused by macro changes, for example COPYCHAR
was changed from memcpy to ts_copychar_cstr. That doesn't seem to be
an actual issue, but it could have been with a different change, and I
think similarly could go unnoticed.

There are also cases where something was simply removed from public
headers (firstbyte64(v) define from hashfn_unstable.h for example).
This again wouldn't cause any issues as long as the functions called
by it are still there, but it seems to break source compatibility
between minor versions.