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
Re: Unify DLSUFFIX on Darwin |
Список | 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 по дате отправления: