Tom Lane <t...@sss.pgh.pa.us> writes: > Andres Freund <and...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers