Re: Configurable location for extension .control files

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