Re: RFC: Additional Directory for Extensions - Mailing list pgsql-hackers

From Jelte Fennema-Nio
Subject Re: RFC: Additional Directory for Extensions
Date
Msg-id CAGECzQR3_OvvQ1DX91nt-ERhSMR29_NJNjX8Nvo=fp5=5emdzA@mail.gmail.com
Whole thread Raw
In response to Re: RFC: Additional Directory for Extensions  ("David E. Wheeler" <david@justatheory.com>)
Responses Re: RFC: Additional Directory for Extensions
List pgsql-hackers
On Thu, 11 Apr 2024 at 19:52, David E. Wheeler <david@justatheory.com> wrote:
> I realize this probably isn’t going to happen for 17, given the freeze, but I would very much welcome feedback and
pointersto address concerns about providing a second directory for extensions and DSOs. Quite a few people have talked
aboutthe need for this in the Extension Mini Summits[1], so I’m sure I could get some collaborators to make
improvementsor look at a different approach. 

Overall +1 for the idea. We're running into this same limitation (only
a single place to put extension files) at Microsoft at the moment.

+        and to the '$libdir' directive when loading modules
+        that back functions.

I feel like this is a bit strange. Either its impact is too wide, or
it's not wide enough depending on your intent.

If you want to only change $libdir during CREATE EXTENSION (or ALTER
EXTENSION UPDATE), then why not just change it there. And really you'd
only want to change it when creating an extension from which the
control file is coming from extension_destdir.

However, I can also see a case for really always changing $libdir.
Because some extensions in shared_preload_libraries, might want to
trigger loading other libraries that they ship with dynamically. And
these libraries are probably also in extension_destdir.



pgsql-hackers by date:

Previous
From: "David G. Johnston"
Date:
Subject: Re: [PATCH] Add ACL (Access Control List) acronym
Next
From: Jelte Fennema-Nio
Date:
Subject: Re: RFC: Additional Directory for Extensions