Stephen Frost <> 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

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

Dimitri Fontaine     PostgreSQL : Expertise, Formation et Support

*** a/doc/src/sgml/extend.sgml
--- b/doc/src/sgml/extend.sgml
*** 462,467 ****
--- 462,474 ----
          FUNCTION</> commands for C-language functions, so that the script
          files do not need to hard-wire the name of the shared library.
+        <para>
+         The macro <literal>$directory</literal> is supported when found at the
+         very start of the value of this parameter. When
+         used, <literal>$directory</literal> is then substituted with
+         the <literal>directory</literal> control parameter value by
+         PostgreSQL.
+        </para>
*** a/src/backend/commands/extension.c
--- b/src/backend/commands/extension.c
*** 432,437 **** get_extension_script_filename(ExtensionControlFile *control,
--- 432,470 ----
  	return result;
+ /*
+  * Substitute for any macros appearing in the given string.
+  * Result is always freshly palloc'd.
+  */
+ static char *
+ substitute_directory_macro(const char *directory, const char *module_pathname)
+ {
+ 	const char *sep_ptr;
+ 	AssertArg(module_pathname != NULL);
+ 	/* Currently, we only recognize $directory at the start of the string */
+ 	if (module_pathname[0] != '$')
+ 		return pstrdup(module_pathname);
+ 	if ((sep_ptr = first_dir_separator(module_pathname)) == NULL)
+ 		sep_ptr = module_pathname + strlen(module_pathname);
+ 	/* Accept $libdir, just return module_pathname as is then */
+ 	if (strlen("$libdir") == sep_ptr - module_pathname &&
+ 		strncmp(module_pathname, "$libdir", strlen("$libdir")) == 0)
+ 		return pstrdup(module_pathname);
+ 	if (strlen("$directory") != sep_ptr - module_pathname ||
+ 		strncmp(module_pathname, "$directory", strlen("$directory")) != 0)
+ 		ereport(ERROR,
+ 				(errcode(ERRCODE_INVALID_NAME),
+ 				 errmsg("invalid macro module_pathname in: %s",
+ 						module_pathname)));
+ 	return psprintf("%s%s", directory, sep_ptr);
+ }
   * Parse contents of primary or auxiliary control file, and fill in
*** 895,904 **** execute_extension_script(Oid extensionOid, ExtensionControlFile *control,
  		if (control->module_pathname)
  			t_sql = DirectFunctionCall3(replace_text,
! 							  CStringGetTextDatum(control->module_pathname));
  		/* And now back to C string */
--- 928,941 ----
  		if (control->module_pathname)
+ 			char *directory = get_extension_script_directory(control);
+ 			char *module_pathname =
+ 				substitute_directory_macro(directory, control->module_pathname);
  			t_sql = DirectFunctionCall3(replace_text,
! 							  CStringGetTextDatum(module_pathname));
  		/* And now back to C string */
Sent via pgsql-hackers mailing list (
To make changes to your subscription:

Reply via email to