Re: extension_control_path

Hi,

Peter Eisentraut <peter_e@gmx.net> writes:
> On 2/27/14, 6:04 AM, Dimitri Fontaine wrote:
>>    directory = 'local/hstore-new'
>>    module_pathname = '$directory/hstore'
>
> I think your previously proposed patch to add extension_control_path
> plus my suggestion to update existing de facto best practices to not
> include $libdir into the module path name (thus allowing the use of
> dynamic_library_path) will address all desired use cases just fine.

My opinion is that we have two choices: refactoring the current API or
incrementally improving it. In both cases we should make it possible for
the packager to control where any individual module file is loaded from,
with maybe options for the sysadmin to override the packager's choice.

In your proposal, the control moves away from the developer, and that's
a good thing, so you get a +1 from me.

Just please make sure that it's still possible to use full absolute path
for the module path name so that the packager can have control too.

> Moreover, going that way would reuse existing facilities and concepts,
> remove indirections and reduce overall complexity.  This new proposal,
> on the other hand, would go the other way, introducing new concepts,
> adding more indirections, and increasing overall complexity, while
> actually achieving less.

What the $directory proposal achieves is allowing a fully relocatable
extension layout, where you just have to drop a directory anywhere in
the file system and it just works (*).

It just work and allows to easily control which module is loaded and
without having to setup either LD_LIBRARY_PATH, ld.so.conf nor our own
dynamic_library_path.
 * providing that said directory is part of extension_control_path, or   that you copy or move the .control file to
sharedir/extension.

That said, I don't intend to be using it myself, so I won't try and save
that patch in any ways. My position is that Stephen's concern is real
and his idea simple enough while effective, so worth pursuing.

> I see an analogy here.  What we are currently doing is similar to
> hardcoding absolute rpaths into all libraries.  Your proposal is
> effectively to (1) add the $ORIGIN mechanism and (2) make people use
> chrpath when they want to install somewhere else.  My proposal is to get
> rid of all rpaths and just set a search path.  Yes, on technical level,
> this is less powerful, but it's simpler and gets the job done and is
> harder to misuse.

What happens if you have more than one 'prefix.so' file in your path?

> A problem with features like these is that they get rarely used but
> offer infinite flexibility, so they are not used consistently and you
> can't rely on anything.  This is already the case for the
> module_pathname setting in the control file.  It has, AFAICT, no actual
> use, and because of that no one uses it, and because of that, there is
> no guarantee that extensions use it sensibly, and because of that no one
> can ever make sensible use of it in the future, because there is no
> guarantee that extensions have it set sensibly.  In fact, I would
> propose deprecating module_pathname.

The module_pathname facility allows the packager to decide where the
library module file gets installed and the extension author not to
concern himself with that choice.

I agree that using $libdir as the extension developer isn't the right
thing to do. Having to choose the installation path as a developer,
either in the SQL script or in the control file, is not the right thing.

Now, the practical answer I have to that point is to have the packager
rewrite the control file as part of its build system.

My vote goes against deprecating module_pathname, because I didn't see
in your proposal any ways to offer the control back to the packager,
only to the sysadmin, and I don't want to have the sysadmin involved if
we can avoid it (as you say, too much flexibility is a killer).

In practical term, though, given the current situation, the build system
I'm woking on already has to edit the SQL scripts and control files
anyways…

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