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 по дате отправления: