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(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 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