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

From David E. Wheeler
Subject Re: RFC: Additional Directory for Extensions
Date
Msg-id 3AA66D08-D3C1-409E-A120-721ACF923EC6@justatheory.com
Whole thread Raw
In response to Re: RFC: Additional Directory for Extensions  ("David E. Wheeler" <david@justatheory.com>)
Responses Re: RFC: Additional Directory for Extensions
List pgsql-hackers
Hi Peter,

Making another pass at this proposal, I’m a bit confused by this issue:

On Nov 12, 2024, at 09:44, David E. Wheeler <david@justatheory.com> 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?

Best,

David




pgsql-hackers by date:

Previous
From: Jim Jones
Date:
Subject: Re: Logging which local address was connected to in log_line_prefix
Next
From: Bruce Momjian
Date:
Subject: Re: Statistics Import and Export