From: Tom Lane <tgl@sss.pgh.pa.us>
To: pgsql-hackers@lists.postgresql.org
Subject: Our ABI diff infrastructure ignores enum SysCacheIdentifier
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----- =_aaaaaaaaaa0"
Content-ID: <289116.1770913051.0@sss.pgh.pa.us>
Date: Thu, 12 Feb 2026 11:17:37 -0500
Message-ID: <289125.1770913057@sss.pgh.pa.us>
Archived-At: <https://www.postgresql.org/message-id/289125.1770913057%40sss.pgh.pa.us>
Precedence: bulk

------- =_aaaaaaaaaa0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <289116.1770913051.1@sss.pgh.pa.us>

I discovered $SUBJECT while working on commits dbb09fd8e et al.
The point of those commits was to back-patch addition of a syscache
that previously existed only in v18+, so naturally I was concerned
about not breaking ABI by changing any existing syscache's ID.
I tested whether abidiff would bleat about it if I intentionally
changed an ID, and found that *it didn't*.

I don't think this is (quite) a bug in libabigail.  They are pretty
clear that what they regard as ABI is:

       ... the descriptions of the types reachable by the interfaces
       (functions and variables) that are visible outside of their
       translation unit.

We do not use enum SysCacheIdentifier as the declared type of any
global variable or any globally-visible function argument or result.
Therefore it's not ABI per their definition.

This is frankly pretty scary.  Now that we know the rules, we can
fix it for enum SysCacheIdentifier, but we have other things that are
similarly vulnerable.  The thing I am most concerned about right now
is enum GUCs.  The guc.c APIs mandate that those be declared as type
int, so I think (haven't actually checked) that most if not all of
the associated enum values will not be perceived as ABI-relevant by
abidiff.  What can we do about that?

As for SysCacheIdentifier, the root of the problem is that
SearchSysCache and friends are declared to take "int cacheId"
not "enum SysCacheIdentifier cacheId".  Likely we should change
that in HEAD, but that'd be an actual not theoretical ABI break
(the enum's not necessarily int-width).  In the back branches
I'm thinking about adding a dummy function just for this purpose,
more or less as in the under-commented patch attached.

Thoughts?

			regards, tom lane


------- =_aaaaaaaaaa0
Content-Type: text/x-diff;
	name="0001-make-SysCacheIdentifier-be-part-of-ABI.patch";
	charset="us-ascii"
Content-ID: <289116.1770913051.2@sss.pgh.pa.us>
Content-Description: 0001-make-SysCacheIdentifier-be-part-of-ABI.patch
Content-Transfer-Encoding: quoted-printable

commit 12d2a8cd596d63dd908149b9140f527b723585cc
Author: Tom Lane <tgl@sss.pgh.pa.us>
Date:   Sat Jan 10 18:28:39 2026 -0500

    Make SysCacheIdentifier be ABI.

diff --git a/src/backend/utils/cache/syscache.c b/src/backend/utils/cache/=
syscache.c
index f7f4f56a4d2..1af3ab3afdf 100644
--- a/src/backend/utils/cache/syscache.c
+++ b/src/backend/utils/cache/syscache.c
@@ -671,6 +671,14 @@ GetSysCacheHashValue(int cacheId,
 	return GetCatCacheHashValue(SysCache[cacheId], key1, key2, key3, key4);
 }
 =

+/*
+ * Dummy function with an "enum SysCacheIdentifier" parameter.
+ */
+void
+SysCacheDummy(enum SysCacheIdentifier cacheId)
+{
+}
+
 /*
  * List-search interface
  */
diff --git a/src/include/utils/syscache.h b/src/include/utils/syscache.h
index b541911c8fc..052c4550d22 100644
--- a/src/include/utils/syscache.h
+++ b/src/include/utils/syscache.h
@@ -72,6 +72,8 @@ extern Datum SysCacheGetAttrNotNull(int cacheId, HeapTup=
le tup,
 extern uint32 GetSysCacheHashValue(int cacheId,
 								   Datum key1, Datum key2, Datum key3, Datum key4);
 =

+extern void SysCacheDummy(enum SysCacheIdentifier cacheId);
+
 /* list-search interface.  Users of this must import catcache.h too */
 struct catclist;
 extern struct catclist *SearchSysCacheList(int cacheId, int nkeys,

------- =_aaaaaaaaaa0--