Re: BUG #19506: LOAD '$libdir/...' inside extension scripts ignores dynamic_library_path with extension_control_path

Hi everyone,

I realised I hadn't sent this email with the patch. Please find the
attached patch.

Thanks,
Gabriele

On Fri, 5 Jun 2026 at 22:12, Matheus Alcantara <matheusssilv97(at)gmail(dot)com>
wrote:

> 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(dot)bartolini(at)gmail(dot)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
>
>
>

--
Gabriele Bartolini
VP, Chief Architect, Kubernetes
enterprisedb.com / Melbourne, Australia