On 03/04/2015 09:41 AM, Oskari Saarenmaa wrote:
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.
Hmm. I think you're on to something with this patch, but I couldn't
exactly figure out what. What is the purpose of this patch?
I can see a few things that you might want to do:
1. You might want to create a cluster using existing binaries, and set
it up so that you can install extra extensions from a custom directory.
Handy if you don't have write access to /usr, or you only want to make
an extension available in one cluster but not others.
2. Like 1, but you want to replace the set of set of extensions altogether.
3. Writing an automated regression test for a custom extension.
With all of those, you have the problem that you actually want to
override both the lib-dir and the extensions-dir. So you'll need to set
dynamic_library_path too. For 3, fiddling with the configuration file is
a bit tedious. And PGXS doesn't currently have support for setting up a
test cluster anyway.
Oh, and why are we only worried about extensions? There's other stuff in
'share'-directory that you might also want to override in some clusters
or as part of regression tests: timezone and tsearch data.
Note that you can make Postgres to search for all of those things in a
different directory by copying the "postgres" binary elsewhere. It's a
bit hacky, but works.
- Heikki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
