On Wed, 28 Aug 2024 at 03:26, David E. Wheeler <da...@justatheory.com> wrote:
> 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`?
`pg_config` only cares about compile-time settings, so I would not
expect its output to change.
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.
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.
> 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.
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.
> OTOH, we have this patch now, and this other stuff is just a proposal. Actual
> code trumps ideas in my mind.
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 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 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.
