Re: Configurable location for extension .control files

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 <andres(at)2ndquadrant(dot)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