* Dimitri Fontaine (dimi...@2ndquadrant.fr) wrote: > Stephen Frost <sfr...@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
signature.asc
Description: Digital signature