Re: RFC: Additional Directory for Extensions

From: Peter Eisentraut <peter(at)eisentraut(dot)org>
To: "David E(dot) Wheeler" <david(at)justatheory(dot)com>
Cc: Craig Ringer <craig(dot)ringer(at)enterprisedb(dot)com>, Gabriele Bartolini <gabriele(dot)bartolini(at)enterprisedb(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: RFC: Additional Directory for Extensions
Date: 2024-11-20 09:05:32
Message-ID: 4baa596e-f6f3-4619-96ad-26382f6986a3@eisentraut.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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 that way. The obvious solution is that extensions change this to just 'foo'. But this will require a lot updating work for many 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 the MODULE_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.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrey M. Borodin 2024-11-20 09:07:48 Re: pg_prepared_xacts returns transactions that are foreign to the caller
Previous Message Masahiro Ikeda 2024-11-20 09:04:19 Re: Adding skip scan (including MDAM style range skip scan) to nbtree