Re: RFC: Additional Directory for Extensions - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: RFC: Additional Directory for Extensions
Date
Msg-id 4baa596e-f6f3-4619-96ad-26382f6986a3@eisentraut.org
Whole thread Raw
In response to Re: RFC: Additional Directory for Extensions  ("David E. Wheeler" <david@justatheory.com>)
List 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 by date:

Previous
From: vignesh C
Date:
Subject: Re: Introduce XID age and inactive timeout based replication slot invalidation
Next
From: "Andrey M. Borodin"
Date:
Subject: Re: pg_prepared_xacts returns transactions that are foreign to the caller