Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3776.700.51\))
Subject: Re: RFC: Additional Directory for Extensions
From: "David E. Wheeler" <david@justatheory.com>
In-Reply-To: <CAGRY4ny=Oy-F0qCRFQa=XtEqyUbMygvbqqKahAvbae7v4LTOrQ@mail.gmail.com>
Date: Tue, 27 Aug 2024 11:26:15 -0400
Cc: Gabriele Bartolini <gabriele.bartolini@enterprisedb.com>,
 Robert Haas <robertmhaas@gmail.com>,
 Alvaro Herrera <alvherre@alvh.no-ip.org>,
 PostgreSQL-development <pgsql-hackers@postgresql.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <AF4A50CD-C5CF-406D-9700-1B889F40E8FB@justatheory.com>
References: <CA+TgmoaMk==vOUmWwJ5ZA-EueNqa9RQaWMEiHCF1ZKW_YCcj8g@mail.gmail.com>
 <202406251012.brdp2dobkf7n@alvherre.pgsql>
 <CA+TgmoYcAmhnSUHKdJsS1wOR-9+y6dbLhfJ3Ad+iZEDmA1mPXg@mail.gmail.com>
 <FE1622BC-81BB-487B-BF0A-4D29906F8F47@justatheory.com>
 <C0393253-B71B-4AF9-87DA-A831AC8B3836@justatheory.com>
 <CA+VUV5oWkMVvtNB0BG2CM8SrmOkeW6fEtXGehbniHqR9MhMzVw@mail.gmail.com>
 <CAGRY4nxP6A5Dz23g+aGD-agdVwUj_qrG6szd-mWc0E5OFMBg4w@mail.gmail.com>
 <B86AF59F-5B65-4CC9-91A4-B79A089C2876@justatheory.com>
 <CAGRY4ny=Oy-F0qCRFQa=XtEqyUbMygvbqqKahAvbae7v4LTOrQ@mail.gmail.com>
To: Craig Ringer <craig.ringer@enterprisedb.com>
Archived-At: <https://www.postgresql.org/message-id/AF4A50CD-C5CF-406D-9700-1B889F40E8FB%40justatheory.com>
Precedence: bulk

On Aug 26, 2024, at 17:35, Craig Ringer <craig.ringer@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,=20

SET extension_search_path =3D $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=E2=80=99s 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=E2=80=99ve 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=E2=80=99d 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 =E2=80=9Cget some clarity=E2=80=9D because my proposal =
doesn=E2=80=99t require recursing, and I=E2=80=99m not sure why it=E2=80=99=
d be needed.

Best,

David