On Nov 12, 2024, at 08:25, Peter Eisentraut <pe...@eisentraut.org> wrote:
> No, you can also install them into a common directory and mount that one.
> For example, you install the extension at build time into
> /tmp/foo/{lib,share/extension}, you package that up as a disk image, mount it
> at /opt/extensions/myext, and then 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 into which it’s being installed right
>> now?”. Doesn’t seem necessary to search a path if the specific location is
>> set at install time.
>
> No, this is not set at build or install time. This is for typical extensions
> hardcoded, and $libdir is resolved by the PostgreSQL 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 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.
Yeah, '$libdir/foo' has been the documented way to do it for quite some time,
as I recall. Perhaps the behavior of the MODULE_PATHNAME replacement 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 file location along the lines of
>> the other thread[2] and the RFC I’m working up based on them both[1],
>> especially since there are 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 doubt it’d take much to use this
patch as the first step toward it.
Best,
David
[1]: https://github.com/theory/justatheory/pull/7/files
