Re: Configurable location for extension .control files

From: Oskari Saarenmaa <os(at)ohmu(dot)fi>
To: hlinnaka(at)iki(dot)fi, Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com>, Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr>, Andres Freund <andres(at)2ndquadrant(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Oliver Charles <ollie(at)ocharles(dot)org(dot)uk>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Configurable location for extension .control files
Date: 2015-07-02 20:37:15
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

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

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2015-07-02 20:42:35 Re: [PATCH] two-arg current_setting() with fallback
Previous Message Andres Freund 2015-07-02 20:28:20 Re: Add checksums without --initdb