Re: dfmgr additional ABI version fields - Mailing list pgsql-hackers

From Tom Lane
Subject Re: dfmgr additional ABI version fields
Date
Msg-id 82163.1633624943@sss.pgh.pa.us
Whole thread Raw
In response to Re: dfmgr additional ABI version fields  (Andres Freund <andres@anarazel.de>)
Responses Re: dfmgr additional ABI version fields  (Chapman Flack <chap@anastigmatix.net>)
List 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
sucha 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



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: storing an explicit nonce
Next
From: Mark Dilger
Date:
Subject: Re: Role Self-Administration