Re: extension_control_path

From: Peter Eisentraut <peter_e(at)gmx(dot)net>
To: Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr>, Stephen Frost <sfrost(at)snowman(dot)net>
Cc: Sergey Muraviov <sergey(dot)k(dot)muraviov(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: extension_control_path
Date: 2014-02-28 03:29:23
Message-ID: 53100293.5080701@gmx.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2/27/14, 6:04 AM, Dimitri Fontaine wrote:
> What about allowing a control file like this:
>
> # hstore extension
> comment = 'data type for storing sets of (key, value) pairs'
> default_version = '1.3'
> directory = 'local/hstore-new'
> module_pathname = '$directory/hstore'
> relocatable = true
>
> The current way directory is parsed, relative pathnames are allowed and
> will be resolved in SHAREDIR, which is where we find the extension/ main
> directory, where currently live extension control files.
>
> With such a feature, we would allow module_pathname to reuse the same
> location as where we're going to find auxilliary control files and
> scripts.

If I understand this correctly, then installing an extension in a
nonstandard directory would require editing (or otherwise changing) the
control file.

That doesn't seem very attractive. In fact, it would fail my main use
case for all of this, which is being able to test extensions before
installing them.

I think we should get rid of the module_pathname business, and
extensions' SQL files should just refer to the base file name and rely
on the dynamic library path to find the files. What would we lose if we
did that?

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2014-02-28 04:04:00 Re: jsonb and nested hstore
Previous Message Andrew Dunstan 2014-02-28 03:27:55 Re: jsonb and nested hstore