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: <CAGRY4nx8Fmea4udk--PKdvfgpNdqC+rcueAmGwuw2PD9dv+zqQ@mail.gmail.com>
Date: Thu, 29 Aug 2024 11:55:27 -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: <D30A91FA-A6D4-4737-941F-0BBB2984B730@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>
 <AF4A50CD-C5CF-406D-9700-1B889F40E8FB@justatheory.com>
 <CAGRY4nx8Fmea4udk--PKdvfgpNdqC+rcueAmGwuw2PD9dv+zqQ@mail.gmail.com>
To: Craig Ringer <craig.ringer@enterprisedb.com>
Archived-At: <https://www.postgresql.org/message-id/D30A91FA-A6D4-4737-941F-0BBB2984B730%40justatheory.com>
Precedence: bulk

On Aug 27, 2024, at 22:24, Craig Ringer <craig.ringer@enterprisedb.com> =
wrote:

> `pg_config` only cares about compile-time settings, so I would not
> expect its output to change.

Right, of course that=E2=80=99s its original purpose, but extensions =
depend on it to determine where to install extensions. Not just PGXS, =
but also pgrx and various Makefile customizations I=E2=80=99ve seen in =
the wild.

> I suspect we'd have to add PGXS extension-path awareness if going for
> per-extension subdir support. I'm not sure it makes sense to teach
> `pg_config` about this, since it'd need to have a different mode like
>=20
>    pg_config --extension myextname --extension-sharedir
>=20
> since the extension's "sharedir" is
> $basedir/extensions/myextension/share or whatever.

Right. PGXS would just need to know where to put the directory for an =
extension. There should be a default for the project, and then it can be =
overridden with something like DESTDIR (but without full paths under =
that prefix).

> Supporting this looks to be a bit intrusive in the makefiles,
> requiring them to differentiate between "share dir for extensions" and
> "share dir for !extensions", etc. I'm not immediately sure if it can
> be done in a way that transparently converts unmodified extension PGXS
> makefiles to target the new paths; it might require an additional
> define, or use of new variables and an ifdef block to add
> backwards-compat to the extension makefile for building on older
> postgres.

Yeah, might just have to be an entirely new thing, though it sure would =
be nice for existing PGXS-using Makefiles to do the right thing. Maybe =
for the new version of the server with the proposed new pattern it would =
dispatch to the new thing somehow without modifying all the rest of its =
logic.

> Right. The proposed structure is rather a bigger change than I was
> thinking when I suggested supporting an extension search path not just
> a single extra path. But it's also a cleaner proposal; the
> per-extension directory would make it easier to ensure that the
> extension control file, sql scripts, and dynamic library all match the
> same extension and version if multiple ones are on the path. Which is
> desirable when doing things like testing a new version of an in-core
> extension.

=F0=9F=92=AF

> Right. And I've been on the receiving end of having a small, focused
> patch derailed by others jumping in and scope-exploding it into
> something completely different to solve a much wider but related
> problem.

I=E2=80=99m not complaining, I would definitely prefer to see consensus =
on a cleaner proposal along the lines we=E2=80=99ve discussed and a =
commitment to time from parties able to get it done in time for v18. =
I=E2=80=99m willing to help where I can with my baby C! Failing that, we =
can fall back on the destdir patch.

> I'm definitely not trying to stand in the way of progress with this; I
> just want to make sure that it doesn't paint us into a corner that
> prevents a more general solution from being adopted later. That's why
> I'm suggesting making the config a multi-value string (list of paths)
> and raising a runtime "ERROR: searching multiple paths for extensions
> not yet supported" or something if >1 path configured.
>=20
> If that doesn't work, no problem.

I think the logic would have to be different, so they=E2=80=99d be =
different GUCs with their own semantics. But if the core team and =
committers are on board with the general idea of search paths and =
per-extension directory organization, it would be best to avoid getting =
stuck with maintaining the current patch=E2=80=99s GUC.

OTOH, we could get it committed now and revert it later if we get the =
better thing done and committed.

>> 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=99d be needed.
>=20
> =46rom what you and Gabriele are discussing (which I agree with), it =
wouldn=E2=80=99t.

Ah, great.

I=E2=80=99ll try to put some thought into a more formal proposal in a =
new thread next week. Unless your Gabriele beats me to it =F0=9F=98=82.

Best,

David