Re: extension_control_path

* Dimitri Fontaine (dimitri(at)2ndQuadrant(dot)fr) wrote:
> Stephen Frost <sfrost(at)snowman(dot)net> writes:
> > me as a terrible idea to ship absolute object file names (which I assume
> > you mean to include path, given you say 'absolute') unless you're an
>
> I agree, that's why my current design also needs cooperation on the
> backend side of things, to implement what you're calling here relocation
> of the files. Now that I read your comments, we might be able to
> implement something really simple and have something in core…

I didn't really expect this to be a huge issue or hard problem to
implement.. :)

> Please see attached patch, tested and documented.

On a quick glance-over, it looks like a reasonable implementation to me.

> 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

Interesting idea. I'm a *little* concerned that re-useing '$directory'
there might confuse people into thking that any values in the control
file could be substituted in a similar way though. Would there really
be much difference between that and '$ctldir' or something?

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

Sure, though it's unlikely to be used much there, as it's managed by the
packagers.

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

Right- they'd be able to have everything in a single directory,
presumably one where they're doing development or where some other
installers installs to.

> Given module_pathname = '$directory/xxx' the extension is now fully
> relocatable and the tool doesn't need to put in any other effort than
> hacking the control file *at build time*.

Right.

Peter, any thoughts on this approach..?

Thanks,

Stephen