Re: RFC: Additional Directory for Extensions
От | Peter Eisentraut |
---|---|
Тема | Re: RFC: Additional Directory for Extensions |
Дата | |
Msg-id | 4baa596e-f6f3-4619-96ad-26382f6986a3@eisentraut.org обсуждение исходный текст |
Ответ на | Re: RFC: Additional Directory for Extensions ("David E. Wheeler" <david@justatheory.com>) |
Ответы |
Re: RFC: Additional Directory for Extensions
|
Список | pgsql-hackers |
On 18.11.24 20:19, David E. Wheeler wrote: >>>>> - The biggest problem is that many extensions set in their control file >>>>> >>>>> module_pathname = '$libdir/foo' >>>>> >>>>> This disables the use of dynamic_library_path, so this whole idea of installing an extension elsewhere won't work thatway. The obvious solution is that extensions change this to just 'foo'. But this will require a lot updating work formany extensions, or a lot of patching by packagers. >> >> Yeah, '$libdir/foo' has been the documented way to do it for quite some time, as I recall. Perhaps the behavior of theMODULE_PATHNAME replacement function could be changed to omit $libdir when writing the SQL files? > > Elsewhere you write: > >> Nothing changes about shared library files. They are looked up in dynamic_library_path or any hardcoded file name. > > And also point out that the way to install them is: > > ``` > make install datadir=/else/where/share pkglibdir=/else/where/lib > ``` > > So as long as dynamic_library_path includes /else/where/lib it should work, just as before, no? The path is only consulted if the specified name does not contain a slash. So if you do LOAD 'foo', the path is consulted, but if you do LOAD '$libdir/foo', it is not. The problem I'm describing is that most extensions use the latter style, per current recommendation in the documentation.
В списке pgsql-hackers по дате отправления: