Re: extension_control_path

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.

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

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company