Stephen Frost <sfr...@snowman.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
*** 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>
+ <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>
</listitem>
</varlistentry>
*** 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,
t_sql,
CStringGetTextDatum("MODULE_PATHNAME"),
! 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,
t_sql,
CStringGetTextDatum("MODULE_PATHNAME"),
! CStringGetTextDatum(module_pathname));
}
/* And now back to C string */
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
