Re: extension_control_path

* Robert Haas (robertmhaas(at)gmail(dot)com) wrote:
> On Fri, Mar 7, 2014 at 10:19 PM, Peter Eisentraut <peter_e(at)gmx(dot)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