On Tue, 27 Aug 2024 at 02:07, David E. Wheeler <da...@justatheory.com> wrote: > On Aug 21, 2024, at 19:07, Craig Ringer <craig.rin...@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-based structure for extensions, > where every file for an extension is in a directory named for the extension, > and subdirectories 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 method of 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 modification of 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, solving most of the integration > problems (immutable servers, packaging testing, etc.) at the cost of a > slightly unexpected directory layout. What I mean by that is that the current > patch is pretty much just using extension_destdir as a prefix to all of those > directories from pg_config, so they never have to change, but it does mean > that you end up installing extensions 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
