Re: RFC: Additional Directory for Extensions

Поиск
Список
Период
Сортировка
От walther@technowledgy.de
Тема Re: RFC: Additional Directory for Extensions
Дата
Msg-id fd7b9b4b-e6b8-46f8-95e4-8bc1315eff7f@technowledgy.de
обсуждение исходный текст
Ответ на Re: RFC: Additional Directory for Extensions  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Ответы Re: RFC: Additional Directory for Extensions
Список pgsql-hackers
Alvaro Herrera:
> I support the idea of there being a second location from where to load
> shared libraries ... but I don't like the idea of making it
> runtime-configurable.  If we want to continue to tighten up what
> superuser can do, then one of the things that has to go away is the
> ability to load shared libraries from arbitrary locations
> (dynamic_library_path).  I think we should instead look at making those
> locations hardcoded at compile time.  The packager can then decide where
> those things go, and the superuser no longer has the ability to load
> arbitrary code from arbitrary locations.

The use-case for runtime configuration of this seems to be build-time 
testing of extensions against an already installed server. For this 
purpose it should be enough to be able to set this directory at startup 
- it doesn't need to be changed while the server is actually running. 
Then you could spin up a temporary postgres instance with the extension 
directory pointing a the build directory and test.

Would startup-configurable be better than runtime-configurable regarding 
your concerns?

I can also imagine that it would be very helpful in a container setup to 
be able to set an environment variable with this path instead of having 
to recompile all of postgres to change it.

Best,

Wolfgang



В списке pgsql-hackers по дате отправления:

Предыдущее
От: jian he
Дата:
Сообщение: Re: remaining sql/json patches
Следующее
От: Daniel Gustafsson
Дата:
Сообщение: Re: [HACKERS] make async slave to wait for lsn to be replayed