* Robert Haas ([email protected]) wrote: > On Fri, Mar 7, 2014 at 10:19 PM, Peter Eisentraut <[email protected]> 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
signature.asc
Description: Digital signature
