Re: dfmgr additional ABI version fields
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
Cc: pgsql-hackers@lists.postgresql.org,
Peter Eisentraut <peter.eisentraut@enterprisedb.com>,
pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2021-10-07T16:42:23Z
Lists: pgsql-hackers
Andres Freund <andres@anarazel.de> writes: > On October 7, 2021 8:49:57 AM PDT, Tom Lane >> I'm also kind of unclear on why we need to do anything about this >> in the community version. If someone has forked PG and changed >> APIs to the extent that extensions are unlikely to work, there's >> not much stopping them from also making the two-line change >> to fmgr.h that would be needed to guarantee that different magic >> struct contents are needed. > I can see two reasons. First, it'd probably allow stock pg to generate a better error message when confronted with such a module. Second, there's some value in signaling forks that they should change (or think about changing), that field. Hmm, ok, I can buy the first of those arguments. Less sure about the second, but the first is reason enough. Can we make the addition be a string not a number, so that we could include something more useful than "1234" in the error message? Something like "Module is built for EDB v1234.56" seems like it'd be a lot more on-point to the average user, and it gets us out of having to design the ABI versioning scheme that a fork should use. regards, tom lane
Commits
-
Add ABI extra field to fmgr magic block
- d6d1dfcc99e3 15.0 landed