Re: Configurable location for extension .control files
От | Tom Lane |
---|---|
Тема | Re: Configurable location for extension .control files |
Дата | |
Msg-id | 21333.1370873625@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Configurable location for extension .control files (Dimitri Fontaine <dimitri@2ndQuadrant.fr>) |
Ответы |
Re: Configurable location for extension .control files
|
Список | pgsql-hackers |
Dimitri Fontaine <dimitri@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
В списке pgsql-hackers по дате отправления: