Re: RFC: Additional Directory for Extensions

On Nov 12, 2024, at 08:25, Peter Eisentraut <peter@eisentraut.org> wrote:

> No, you can also install them into a common directory and mount that one.  For example, you install the extension at
buildtime into /tmp/foo/{lib,share/extension}, you package that up as a disk image, mount it at /opt/extensions/myext,
andthen you can point extension_control_path at /opt/extensions/myext/lib and dynamic_library_path at
/opt/extensions/myext/share/extension.

Ah, I see, then you just have to set both GUCs to subdirectories of the one volume.

>> Since that’s set at build/install time, couldn’t the definition of `$libdir` here be changed to mean “the directory
intowhich it’s being installed right now?”. Doesn’t seem necessary to search a path if the specific location is set at
installtime. 
>
> No, this is not set at build or install time.  This is for typical extensions hardcoded, and $libdir is resolved by
thePostgreSQL server at run time. 

I see, so that they could be moved and, as long as dynamic_library_path is updated, would still be findable.

So back to your original caveat:

>>> - 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
thatway.  The obvious solution is that extensions change this to just 'foo'.  But this will require a lot updating work
formany 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_PATHNAMEreplacement function could be changed to omit $libdir when writing the SQL files? 

>> Perhaps I misunderstand, but I would like to talk through the implications of a more radical rethinking of extension
filelocation along the lines of the other thread[2] and the RFC I’m working up based on them both[1], especially since
thereare a few other use cases that inform it. 
>
> I'm aware of that thread, but I think that is looking like a much larger project than what I'm proposing here.

Fair enough. Once we get to some consensus on a design there (and I’ve continued to iterate on it elsewhere[1]), I
doubtit’d take much to use this patch as the first step toward it. 

Best,

David

[1]: https://github.com/theory/justatheory/pull/7/files