Re: extension_control_path

On 3/7/14, 11:39 AM, Dimitri Fontaine wrote:
> 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.

I can't think of any package system where absolute paths are part of a
recommended workflow.  There is always a search path, that search path
contains a series of some kinds of system, non-system, per-user
directories.  A packager or installer chooses one of those directories
as installation target, according to convention or user choice.

OK, you can install a C library in some obscure place and then to
#include </some/absolute/path/file.h>, but that's not sane practice.
Similarly, you will still be able to hardcode paths into CREATE FUNCTION
statements or other places, but why would you want to?

> 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 (*).

If that's what you want (and it sounds attractive), why couldn't we just
locate libraries using extension_control_path as well (which presumably
contains the control file we are just processing).  No need for another
indirection.  Libraries and control files being in separate directory
hierarchies is a historical artifact, but it's not something that can't
be changed if it's not what we want.

The problem I have with this $directory proposal, if I understand it
correctly, is that it requires editing of the control file at
installation time.  I don't like this for three reasons: it's not clear
how this should actually be done, creating more broken extension build
scripts (a big problem already); control files are part of the "code",
so to speak, not a configuration file, and so munging it in a
site-specific way creates a hybrid type of file that will be difficult
to properly manage; it doesn't allow running an extension before
installation (unless I overwrite the control file in my own source
tree), which is my main use case for this.

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

The same thing that happens if you have more than one prefix.control in
your path.  You take the first one you find.

Yes, if those are actually two different path settings, you need to keep
those aligned.  But that would be a one-time setting by the database
administrator, not a per-extension-and-packager setting, so it's
manageable.  If it still bothers you, put them both in the same path, as
I suggested above.

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

Again, that would only work if they patch the control file during
installation, which is dubious.  That's like patching paths in include
files or shared libraries.  People do that, but it's not a preferred
method.  And secondly, why would a packager care?  Has any packager ever
cared to relocate the library file and no other file?

Aside from those details, it seems clear that any reasonably complete
move-extensions-elsewhere feature will need some kind of build system
support.  I have various ideas on that and would gladly contribute some
of them, but it's not going to happen within two weeks.

At this point I suggest that we work toward the minimum viable product:
the extension_control_path feature as originally proposed (plus the
crash fixes), and let the field work out best practices.  As you
describe, you can work around all the other issues by patching various
text files, but you currently cannot move the extension control file in
any way, and that's a real deficiency.  (I once experimented with bind
mounts to work around that -- a real mess ;-) )