Re: Unify DLSUFFIX on Darwin

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Unify DLSUFFIX on Darwin
Дата
Msg-id 348725.1656080031@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Unify DLSUFFIX on Darwin  (Peter Eisentraut <peter.eisentraut@enterprisedb.com>)
Ответы Re: Unify DLSUFFIX on Darwin  (Andrew Dunstan <andrew@dunslane.net>)
Re: Unify DLSUFFIX on Darwin  (Peter Eisentraut <peter.eisentraut@enterprisedb.com>)
Список pgsql-hackers
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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: NAMEDATALEN increase because of non-latin languages
Следующее
От: Andrew Dunstan
Дата:
Сообщение: Re: Make COPY extendable in order to support Parquet and other formats