Re: Configurable location for extension .control files

On 2/17/15 4:39 PM, Oskari Saarenmaa wrote:
> 10.06.2013, 17:51, Dimitri Fontaine kirjoitti:
>> Andres Freund <andres@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