Re: Configurable location for extension .control files

02.07.2015, 20:31, Heikki Linnakangas kirjoitti:
> 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:
>>>> 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.

I'm somewhat interested in both #1 & #2 for other projects, but I wrote
this patch to address #3, i.e. to simplify the test setup we have in
place for pgmemcache
(https://github.com/ohmu/pgmemcache/blob/master/localtests.sh) and other
extensions. I'd like to be able to set up a local PG cluster in /tmp or
some other location and load the extensions I just built in there.
Overriding dynamic_library_path is already possible, but there's
currently no way to test the actual extension .control files.

I don't think "fiddling with a configuration file" is all that bad --
you just run initdb and modify the few lines that you're interested in
using sed or any other tool; that's something you'll have to do to set
port or socket directory 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.

I suppose someone might be interested in using custom timezone data with
existing binaries, but the number of existing third party extensions
must be a lot higher than the number of third party timezone data sets.

/ Oskari