Re: RFC: Additional Directory for Extensions

Поиск
Список
Период
Сортировка
От Jelte Fennema-Nio
Тема Re: RFC: Additional Directory for Extensions
Дата
Msg-id CAGECzQR3_OvvQ1DX91nt-ERhSMR29_NJNjX8Nvo=fp5=5emdzA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: RFC: Additional Directory for Extensions  ("David E. Wheeler" <david@justatheory.com>)
Ответы Re: RFC: Additional Directory for Extensions
Список 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 по дате отправления:

Предыдущее
От: "David G. Johnston"
Дата:
Сообщение: Re: [PATCH] Add ACL (Access Control List) acronym
Следующее
От: Jelte Fennema-Nio
Дата:
Сообщение: Re: RFC: Additional Directory for Extensions