Message-ID: <9ef850b9-d127-44db-9a6c-4db64436b056@gmail.com>
Date: Fri, 5 Jun 2026 09:12:37 -0300
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: BUG #19506: LOAD '$libdir/...' inside extension scripts ignores
 dynamic_library_path with extension_control_path
To: gabriele.bartolini@gmail.com, pgsql-bugs@lists.postgresql.org,
 PG Bug reporting form <noreply@postgresql.org>
References: <19506-9478f3012ecc2328@postgresql.org>
Content-Language: en-US
From: Matheus Alcantara <matheusssilv97@gmail.com>
In-Reply-To: <19506-9478f3012ecc2328@postgresql.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/9ef850b9-d127-44db-9a6c-4db64436b056%40gmail.com>
Precedence: bulk

On 03/06/26 19:21, PG Bug reporting form wrote:
> The following bug has been logged on the website:
> 
> Bug reference:      19506
> Logged by:          Gabriele Bartolini
> Email address:      gabriele.bartolini@gmail.com
> PostgreSQL version: 18.4
> Operating system:   Linux (reproduced under CloudNativePG/Kubernetes)
> Description:
> 
> When an extension is installed in a location reached via
> `extension_control_path` / `dynamic_library_path` (rather than the
> compiled-in package library directory), a LOAD '$libdir/foo' hardcoded
> inside an extension's SQL script fails to find the library. PostGIS does
> this in its upgrade scripts, so a PostGIS upgrade fails:
> 
> ```
> app=# SELECT postgis_extensions_upgrade();
> NOTICE:  Updating extension postgis 3.6.1
> ERROR:  could not access file "$libdir/postgis-3": No such file or directory
> CONTEXT:  SQL statement "LOAD '$libdir/postgis-3'"
> extension script file "postgis--ANY--3.6.3.sql", near line 1530
> ```
> 
> This is a side effect of the fix for bug #18920 (commit f777d773878). Commit
> 4f7f7b03758 (`extension_control_path`) made the feature work by stripping
> the '$libdir/' prefix so that dynamic_library_path is consulted. #18920 then
> restricted that stripping to the function-load path so that a user-issued
> `LOAD` keeps the literal '$libdir/' prefix. As a result, a `LOAD` inside an
> extension script now also keeps the literal prefix, so
> `dynamic_library_path` is never consulted, and the library cannot be found.
> 

The only reason that it was decided that we should strip the $libdir 
was that almost all popular extensions use $libdir prefix on 
module_pathname on .control files, so the extension_control_path would 
not work and waiting for extensions to change this will make the 
extension_control_path almost useless (I hope that we can remove this 
in the future once 18 is the minimum supported version).

I'm not sure if we also want this for the LOAD command, I'm wondering 
if the postgis could remove the $libdir prefix from the LOAD command 
instead of Postgres striping this, what do you think? IIRC a simple 
LOAD 'postgis-3' on versions before 18 will still works.

I think that extensions should start to remove the $libdir prefix 
since extension_control_path is going to the second release cycle, but 
I agree that it seems more complicated than it actually is.

--
Matheus Alcantara
EDB: https://www.enterprisedb.com