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