From: Tom Lane <tgl@sss.pgh.pa.us>
To: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: Unify DLSUFFIX on Darwin
In-reply-to: <f64debe0-0045-9a7b-6af8-6122cc6ce18d@enterprisedb.com>
References: <bcc45f78-e3c3-8fb3-7c42-5371b48b5266@enterprisedb.com>
 <3336874.1655905520@sss.pgh.pa.us>
 <f64debe0-0045-9a7b-6af8-6122cc6ce18d@enterprisedb.com>
Comments: In-reply-to Peter Eisentraut <peter.eisentraut@enterprisedb.com>
	message dated "Fri, 24 Jun 2022 13:26:54 +0200"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <348724.1656080031.1@sss.pgh.pa.us>
Date: Fri, 24 Jun 2022 10:13:51 -0400
Message-ID: <348725.1656080031@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/348725.1656080031%40sss.pgh.pa.us>
Precedence: bulk

Peter Eisentraut <peter.eisentraut@enterprisedb.com> writes:
> On 22.06.22 15:45, Tom Lane wrote:
>> Doesn't this amount to a fundamental ABI break for extensions?
>> Yesterday they had to ship foo.so, today they have to ship foo.dylib.

> Extensions generally only load the module files using the extension-free 
> base name.  And if they do specify the extension, they should use the 
> provided DLSUFFIX variable and not hardcode it.  So I don't see how this 
> would be a problem.

Hm.  Since we force people to recompile extensions for new major versions
anyway, maybe it'd be all right.  I'm sure there is *somebody* out there
who will have to adjust their build scripts, but it does seem like it
shouldn't be much worse than other routine API changes.

[ thinks for a bit... ]  Might be worth double-checking that pg_upgrade
doesn't get confused in a cross-version upgrade.  A quick grep doesn't
find that it refers to DLSUFFIX anywhere, but it definitely does pay
attention to extensions' shared library names.

			regards, tom lane