From: | walther(at)technowledgy(dot)de |
---|---|
To: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, "David E(dot) Wheeler" <david(at)justatheory(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: RFC: Additional Directory for Extensions |
Date: | 2024-04-03 07:57:12 |
Message-ID: | fd7b9b4b-e6b8-46f8-95e4-8bc1315eff7f@technowledgy.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Daniel Gustafsson | 2024-04-03 07:58:29 | Re: [HACKERS] make async slave to wait for lsn to be replayed |
Previous Message | jian he | 2024-04-03 07:15:57 | Re: remaining sql/json patches |