Re: RFC: Additional Directory for Extensions

Thanks for your efforts, a secondary directory for extensions is a very
useful feature.

Is there any updates on the patch?

-Ebru

On Thu, Aug 29, 2024 at 6:55 PM David E. Wheeler <david(at)justatheory(dot)com>
wrote:

> On Aug 27, 2024, at 22:24, Craig Ringer <craig(dot)ringer(at)enterprisedb(dot)com>
> wrote:
>
> > `pg_config` only cares about compile-time settings, so I would not
> > expect its output to change.
>
> Right, of course that’s 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’ve 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
> >
> > pg_config --extension myextname --extension-sharedir
> >
> > 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.
>
> 💯
>
> > 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’m not complaining, I would definitely prefer to see consensus on a
> cleaner proposal along the lines we’ve discussed and a commitment to time
> from parties able to get it done in time for v18. I’m 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.
> >
> > If that doesn't work, no problem.
>
> I think the logic would have to be different, so they’d 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’s 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 “get some clarity” because my proposal doesn’t require
> recursing, and I’m not sure why it’d be needed.
> >
> > From what you and Gabriele are discussing (which I agree with), it
> wouldn’t.
>
> Ah, great.
>
> I’ll try to put some thought into a more formal proposal in a new thread
> next week. Unless your Gabriele beats me to it 😂.
>
> Best,
>
> David
>
>
>
>