18.02.2015, 01:49, Jim Nasby kirjoitti: > On 2/17/15 4:39 PM, Oskari Saarenmaa wrote: >> 10.06.2013, 17:51, Dimitri Fontaine kirjoitti: >>> Andres Freund <and...@2ndquadrant.com> writes: >>>>> In any case, no packager is going to ship an insecure-by-default >>>>> configuration, which is what Dimitri seems to be fantasizing would >>>>> happen. It would have to be local option to relax the permissions >>>>> on the directory, no matter where it is. >>>> >>>> *I* don't want that at all. All I'd like to have is a postgresql.conf >>>> option specifying additional locations. >>> >>> Same from me. I think I would even take non-plural location. >> >> Here's a patch to allow overriding extension installation directory. >> The patch allows superusers to change it at runtime, but we could also >> restrict it to postgresql.conf if needed. I don't really see a point in >> restricting it (or not implementing the option at all) as the superuser >> can already load custom C code and sql from anywhere in the filesystem; >> not having configurable extension directory just makes it harder to test >> extensions and to create private clusters of PG data in a custom >> location without using custom binaries. > > I'm interested in this because it could potentially make it possible to > install SQL extensions without OS access. (My understanding is there's > some issue with writing the extension files even if LIBDIR is writable > by the OS account).
I'm not sure this patch makes extensions without OS access any easier to implement; you still need to write the files somewhere, and someone needs to set up the cluster with a nonstandard extension path. >> I don't think anyone should be packaging and shipping PG with >> extension_directory set, but we really should allow it for superusers >> and postgresql.conf so people can test extensions without hacks like >> this: https://github.com/ohmu/pgmemcache/blob/master/localtests.sh#L23 > > FWIW I'd like to see is breaking the cluster setup/teardown capability > in pg_regress into it's own tool. It wouldn't solve the extension test > problem, but it would eliminate the need for most of what that script is > doing, and it would do it more robustly. It would make it very easy to > unit test things with frameworks other than pg_regress. This would certainly be useful. I can try to do something about it if we get configurable extension path supported. The patch is now in https://commitfest.postgresql.org/5/170/ / Oskari -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
