From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Unify DLSUFFIX on Darwin |
Date: | 2022-06-24 14:13:51 |
Message-ID: | 348725.1656080031@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2022-06-24 14:14:01 | Re: Make COPY extendable in order to support Parquet and other formats |
Previous Message | Tom Lane | 2022-06-24 14:08:41 | Re: NAMEDATALEN increase because of non-latin languages |