Tom Lane <tgl@sss.pgh.pa.us> writes:
> Andres Freund <andres@2ndquadrant.com> writes:
>> I don't really care much about Oliver's usecase TBH, but I would very much
>> welcome making it easier for application developers to package part of
>> ther in-database application code as extensions without either requiring
>> a selfcompiled postgres with a custom extension dir or them having have
>> root access to the machine running postgres.
>
> Well, if you're installing an extension that includes C code, you're
> going to need root access anyway to install the shlib (at least on
> conservatively-configured machines).
At most places, that means you require the extension to be properly
packaged (RPM or DEB or something else) in a way that the sysadmins are
able to manage it in production.
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?
> For pure-SQL extensions, Dimitri's
> been pushing a different approach that needn't involve the filesystem at
> all. We didn't get that finished in 9.3 but I think it's still on the
> agenda for 9.4.
Yes it is. The patch is listed in for the next commitfest, I intend to
check about bitrot and update it before the CF starts.
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support