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 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.
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
