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 ;-) ) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers