On Tue, 27 Aug 2024 at 02:07, David E. Wheeler <david@justatheory.com> wrote:
> On Aug 21, 2024, at 19:07, Craig Ringer <craig.ringer@enterprisedb.com> wrote:
> But even if it’s just one or two, the only proper way an extension directory would work, IME, is to define a
directory-basedstructure for extensions, where every file for an extension is in a directory named for the extension,
andsubdirectories are defined for each of the above requisite file types.
> [...]
> I think this would be a much nicer layout for packaging, installing, and managing extensions versus the current
methodof strewing files around to a slew of different directories.
This looks like a good suggestion to me, it would make the packaging,
distribution and integration of 3rd party extensions significantly
easier without any obvious large or long term cost.
> But it would come at some cost, in terms of backward with the existing layout (or migration to it), significant
modificationof the server to use the new layout (and extension_search_path), and other annoyances like PATH and MANPATH
management.
Also PGXS, the windows extension build support, and 3rd party cmake
builds etc. But not by the looks a drastic change.
> Long term I think it would be worthwhile, but the current patch feels like a decent interim step we could live with,
solvingmost of the integration problems (immutable servers, packaging testing, etc.) at the cost of a slightly
unexpecteddirectory layout. What I mean by that is that the current patch is pretty much just using extension_destdir
asa prefix to all of those directories from pg_config, so they never have to change, but it does mean that you end up
installingextensions in something like:
>
> /mnt/extensions/pg16/usr/share/postgresql/16
> /mnt/extensions/pg16/usr/include/postgresql
My only real concern with the current patch is that it limits
searching for extensions to one additional configurable location,
which is inconsistent with how things like the dynamic_library_path
works. Once in, it'll be difficult to change or extend for BC, and if
someone wants to add a search path capability it'll break existing
configurations.
Would it be feasible to define its configuration syntax as accepting a
list of paths, but only implement the semantics for single-entry lists
and ERROR on multiple paths? That way it could be extended w/o
breaking existing configurations later.
With that said, I'm not the one doing the work at the moment, and the
functionality would definitely be helpful. If there's agreement on
supporting a search-path or recursing into subdirectories I'd be
willing to have a go at it, but I'm a bit stale on Pg's codebase now
so I'd want to be fairly confident the work wouldn't just be thrown
out.
--
Craig Ringer
