Re: extension_control_path

Stephen Frost <sfrost(at)snowman(dot)net> writes:
> I'm a bit confused here- above you '+1'd packagers/sysadmins, but then
> here you are saying that hackers will be setting it? Also, it strikes

Well I was then talking about how it works today, as in PostgreSQL 9.1,
9.2 and 9.3, and most certainly 9.4 as we're not trying to change
anything on that front.

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

Please see attached patch, tested and documented.

doc/src/sgml/extend.sgml | 7 ++++++
src/backend/commands/extension.c | 39 +++++++++++++++++++++++++++++++-
2 files changed, 45 insertions(+), 1 deletion(-)

> Presumably, that's what you'd want to set both the control path and the
> dynamic extension path to- a directory of control files and a directory
> of .so's, or perhaps one combined directory of both, for the simplest
> setup. If you're working with a directory-per-package, then wouldn't
> you want to have everything for that package in that package's directory
> and then only have to add all those directories to one place in
> postgresql.conf?

That's a fair-enough observation, that targets a use case where you're
using the feature without the extra software. I also note that it could
simplify said software a little bit.

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.

> My questions about this are mostly covered above, but I did want to get
> clarification- is this going to be on a per-system basis, as in, when
> the package is installed through your tool, it's going to go figure out
> where the package got installed to and rewrite the control file? Seems
> like a lot of work if you're going to have to add that directory to the
> postgresql.conf path for the control file anyway to then *also* have to
> hack up the control file itself.

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

See the attached patch that implements the idea.

Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support