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.