From: | "David E(dot) Wheeler" <david(at)justatheory(dot)com> |
---|---|
To: | Craig Ringer <craig(dot)ringer(at)enterprisedb(dot)com> |
Cc: | Gabriele Bartolini <gabriele(dot)bartolini(at)enterprisedb(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: RFC: Additional Directory for Extensions |
Date: | 2024-08-27 15:26:15 |
Message-ID: | AF4A50CD-C5CF-406D-9700-1B889F40E8FB@justatheory.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Aug 26, 2024, at 17:35, Craig Ringer <craig(dot)ringer(at)enterprisedb(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Nathan Bossart | 2024-08-27 15:26:59 | Re: Enable data checksums by default |
Previous Message | David E. Wheeler | 2024-08-27 15:19:48 | Re: RFC: Additional Directory for Extensions |