Re: RFC: Additional Directory for Extensions
Jelte Fennema-Nio <postgres@jeltef.nl>
From: Jelte Fennema-Nio <postgres@jeltef.nl>
To: "David E. Wheeler" <david@justatheory.com>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>,
walther@technowledgy.de, Alvaro Herrera <alvherre@alvh.no-ip.org>, Christoph Berg <myon@debian.org>
Date: 2024-06-24T21:17:14Z
Lists: 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 pointers to address concerns about providing a second directory for extensions and DSOs. Quite a few people have talked about the need for this in the Extension Mini Summits[1], so I’m sure I could get some collaborators to make improvements or 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.
Commits
-
doc: Flesh out extension docs for the "prefix" make variable
- 0064020680c1 18.0 landed
-
Fix extension control path tests
- b7076c1e7f43 18.0 landed
-
extension_control_path
- 4f7f7b037585 18.0 landed