Re: Configurable location for extension .control files

From: Craig Ringer <craig(at)2ndquadrant(dot)com>
To: Tom Dunstan <pgsql(at)tomd(dot)cc>
Cc: Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Configurable location for extension .control files
Date: 2013-06-12 04:49:20
Message-ID: 51B7FDD0.5090803@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 06/12/2013 08:52 AM, Tom Dunstan wrote:
> Hi Josh
>
> On 11 June 2013 04:37, Josh Berkus <josh(at)agliodbs(dot)com> wrote:
>
>> I don't personally see a reason for plural locations, but it would be
>> nice if it recursed (that is, looked for .so's in subdirectories). My
>> reason for this is that I work on applications which have in-house
>> extensions as well as public ones, and I'd like to keep the two
>> separated by directory.
>
>
> I gave one example of a use-case for multiple directories upthread - the
> Postgres.app mac app has contrib, plv8 and postgis bundled under its
> application folder, but it would be nice to allow users to drop extra
> extensions under ~/Library/Postgres.app somewhere.

Postgres.app is the source of quite a lot of other pain too, though. One
of the bigger problems is that people want/need to link to its libpq
from client drivers like Ruby's Pg gem, but almost inevitably instead
link to libpq from Apple's ancient pre-installed PostgreSQL.

I think this is a far bigger problem than extension locations, and
people trying to do private per-application packaging trees will have
similar issues.

Without a solution to how to sanely share the client libraries I'm not
sure private-tree-packaged PostgreSQL is interesting enough to really
worry about making extensions easier to install. After all, users can
currently just open Postgres.app as a folder and drop the exts in there,
or use PGXS and "make install", just like usual.

--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2013-06-12 05:03:53 Re: Adding IEEE 754:2008 decimal floating point and hardware support for it
Previous Message Craig Ringer 2013-06-12 04:44:50 Re: Parallell Optimizer