Re: extension_control_path

* Peter Eisentraut (peter_e(at)gmx(dot)net) wrote:
> 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.

It depends on what's in the control file. What this would do is give
developers another option for where the .so resides that means "a
directory relative to the control file", which could be quite handy.

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

Not sure why that wouldn't work...?

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

As I pointed out up-thread, you'd have to keep adding more and more
directories to both the control-filed-paths-to-search plus the
dynamic-shared-libraries

Thanks,

Stephen