Re: extension_control_path - Mailing list pgsql-hackers
From | Stephen Frost |
---|---|
Subject | Re: extension_control_path |
Date | |
Msg-id | 20140310194653.GB12995@tamriel.snowman.net Whole thread Raw |
In response to | Re: extension_control_path (Robert Haas <robertmhaas@gmail.com>) |
List | pgsql-hackers |
* Robert Haas (robertmhaas@gmail.com) wrote: > On Fri, Mar 7, 2014 at 10:19 PM, Peter Eisentraut <peter_e@gmx.net> wrote: > >> 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. > > +1. I agree with this- it wasn't my intent to require any hacking of the control file on install. At least my recollection (and it might be wrong- I'm feeling a bit under-the-weather at the moment..) was that I was looking for a way to explicitly say "look for the .so in the same directory as the control file" and then had another thought of "allow a fully-qualified path to be used for the control file @ CREATE EXTENSION time". > >> 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. > > It's tempting to think that when you install an extension, we should > search the directory where the control file was found for the .so > first - and if so, use THAT library every time, not any other one. Of > course the problem with that is that we'd then need to remember that > in the system catalogs, which might pose a problem in terms of letting > people reorganize the filesystem hierarchy without getting too > bothered about what PostgreSQL is remembering internally. I'd like to be able to specify "same directory as the control file" somehow since that's what I expect non-packaged extensions to mostly want. I also don't like having to hack the control file. Nor do I particularly like having to hack the postgresql.conf every time you add an extension (made doubly worse if you have to hand-edit two paths for every additional extension). I agree that it also presents challenges for how we store that information internally. Thanks, Stephen
pgsql-hackers by date: