Dimitri Fontaine <dimi...@2ndquadrant.fr> writes:
> For sites where they don't have in-house system packagers, it would be
> very welcome to be able to setup PostgreSQL in a way that allows it to
> LOAD the extension's binary code (.so, .dll, .dylib) from a non-root
> owned place even if you installed it from official packages.
> Of course, it wouldn't be activated by default and frowned upon in the
> docs for conservative production environments. The use case still seems
> valid to me, and would nicely complete the Extension Templates facility
> given the right tooling.
> Can I prepare a patch allowing PostgreSQL to load extension control
> files and modules from a non-default place in the file-system? Please?
I don't see the need for this. The sort of situation you're describing
probably has PG installed at a non-default install --prefix anyway, and
thus the "standard" extension directory is already not root-owned.
More generally, it seems pretty insane to me to want to configure a
"trusted" PG installation so that it can load C code from an untrusted
place. The trust level cannot be any higher than the weakest link.
Thus, I don't see a scenario in which any packager would ship binaries
using such an option, even if it existed.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
