Re: extension_control_path - Mailing list pgsql-hackers

Stephen Frost <sfrost@snowman.net> writes:
> This is true and Debian puts the control/sql files into a different
> directory than the .so files, of course.  Still, the issue here is how
> we find the .so files- the user *has* to tell us where the control file
> is, if it isn't in the default location, and the assumption (default?)
> is then that the .sql files are co-located with them.  It's at that
> point when we get to the point of trying to figure out what $libdir is

Ok you're migthy confused.

The rules that PostgreSQL follows to know where to load the library from
are not changed *at all* by this patch. In my book, it makes the whole
topic irrelevant to the review.

Futhermore, the rules in question come from two different elements:
 - the object file name in the AS clause, available *separately* for   each and every function definition, to be found
inthe script files:
 
   src/backend/commands/functioncmds.c:744      * For a dynamically linked C language object, the form of the clause is
 *   *       AS <object file name> [, <link symbol name> ]
 
 - the dynamic_library_path GUC that helps interpreting the object file   name when it's not absolute or when it
contains$libdir as its first   characters.
 

If you want to change the rules and provide a way to resolve the object
file name to use on a per-extension level, fee free to propose a patch.

> Yeah, but it seems to be pretty rarely used and the expectation is that
> the .sql files resides in the same directory.  I think what we're
> looking for here, in some ways, is for that default for .so's to work
> out the same- except that right now, the users seem to all default to
> sticking in $libdir.

It used to be a script.sql.in containing AS 'MODULE_PATHNAME', which
would then be replaced with $libdir by pgxs.mk (the rule is still here
in the file). Nowadays we have the replacement facility in the backend,
driven by the module_pathname property in the extension's control file.

Contrib modules are still using the AS 'MODULE_PATHNAME' spelling with
the extension control file spelling module_pathname = '$libdir/xxx'.

Nothing changes with this patch other than where to find the extension
control file. How to resolve the <object file name> on the file system
is still the distribution and local admin problem.

That the controlling of where to find the dynamic libs is convoluted and
involves other people than just the PostgreSQL backend packager might be
seen as a problem or a great flexibility, in any case I don't see what
it has to do with reviewing the extension_control_path patch.

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