Re: RFC: Additional Directory for Extensions

On 11.11.24 08:16, Peter Eisentraut wrote:
> I implemented a patch along the lines Craig had suggested.  It's a new
> GUC variable that is a path for extension control files.  It's called
> extension_control_path, and it works exactly the same way as
> dynamic_library_path.  Except that the magic token is called $system
> instead of $libdir.  In fact, most of the patch is refactoring the
> routines in dfmgr.c to not hardcode dynamic_library_path but allow
> searching for any file in any path.  Once a control file is found, the
> other extension support files (script files and auxiliary control files)
> are looked for in the same directory.

> There are some TODOs in the patch.  Some of those are for documentation
> that needs to be completed.  Others are for functions like
> pg_available_extensions() that need to be rewritten to be aware of the
> path.  I think this would be pretty straightforward.

I've made a bit of progress on this patch, filled in some documentation
and resolved some TODO markers. Also:

> Some open problems or discussion points:
>
> - You can install extensions into alternative directories using PGXS like
>
>     make install datadir=/else/where/share pkglibdir=/else/where/lib
>
> This works.  I was hoping it would work to use
>
>     make install prefix=/else/where
>
> but that doesn't because of some details in Makefile.global.  I think we
> can tweak that a little bit to make that work too.

This works now.

> - 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.

I have solved this by just stripping off "$libdir/" from the front of
the filename. This works for now. We can think about other ways to
tweak this, perhaps, but I don't see any drawback to this in practice.

This patch is now complete enough for testing, I think. As I mentioned
earlier, I haven't updated pg_available_extensions() etc. to support the
path, but that shouldn't prevent some testing.