* Dimitri Fontaine (dimitri@2ndQuadrant.fr) wrote:
> Stephen Frost <sfrost@snowman.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
