On Aug 26, 2024, at 17:35, Craig Ringer <craig.rin...@enterprisedb.com> wrote:
> 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. Yes! > Also PGXS, the windows extension build support, and 3rd party cmake > builds etc. But not by the looks a drastic change. Right. ISTM it could complicate PGXS quite a bit. If we set, say, SET extension_search_path = $extsdir, /mnt/extensions/pg16, /mnt/extensions/pg16/gosuperfast/extensions; What should be the output of `pg_config --sharedir`? > 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. Agreed. > 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. I imagine it’s a simple matter of programming :-) But that leaves the issue of directory organization. The current patch is just a prefix for various PGXS/pg_config directories; the longer-term proposal I’ve made here is not a prefix for sharedir, mandir, etc., but a directory that contains directories named for extensions. So even if we were to take this approach, the directory structure would vary. I suspect we’d have to name it differently and support both long-term. That, too me, is the main issue with this patch. OTOH, we have this patch now, and this other stuff is just a proposal. Actual code trumps ideas in my mind. > 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. I think we should get some clarity on the proposal, and then consensus, as you say. I say “get some clarity” because my proposal doesn’t require recursing, and I’m not sure why it’d be needed. Best, David
