Re: extension_control_path - Mailing list pgsql-hackers

From David E. Wheeler
Subject Re: extension_control_path
Date
Msg-id E7A536C1-9E3E-4DC3-9D53-1AD768E8111D@justatheory.com
Whole thread Raw
In response to Re: extension_control_path  (Sergey Muraviov <sergey.k.muraviov@gmail.com>)
Responses Re: extension_control_path  (Greg Stark <stark@mit.edu>)
List pgsql-hackers
On Jan 30, 2014, at 10:06 AM, Sergey Muraviov <sergey.k.muraviov@gmail.com> wrote:

> Now it looks fine for me.

Just as another data point, I recently submitted pgTAP to the Homebrew project This is the build-from-source system for
OSX, used by a lot of web developers. In my build script, I originally had 
  depends_on :postgresql

Which means, “require any version of PostgreSQL.” But then tests failed on OS X Server, which includes a
system-distributedPostgreSQL. Homebrew installs everything in /usr/local, and not only does it disallow installing
anythingoutside of that directory, it doesn’t have any permissions to do so. The install failed, of course, because
extensionswant to install in $PGROOT/share/extensions. For now, I had to change it to 
  depends_on 'postgresql'

A subtle difference that means, “require the latest version of the Homebrew-built PostgreSQL in /usr/local.”

However, if extension_control_path was supported, I could change it back to requiring any Postgres and install pgTAP
somewhereunder /usr/local, as required for Homebrew. Then all the user would have to do to use it with their preferred
Postgreswould be to set extension_control_path. 

In other words, I am strongly in favor of this patch, as it gives distribution systems a lot more flexibility (for
betterand for worse) in determining where extensions should be installed. 

My $0.02.

Best,

David


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: specifying repeatable read in PGOPTIONS
Next
From: Andrew Dunstan
Date:
Subject: Re: narwhal and PGDLLIMPORT