Re: Configurable location for extension .control files
От | Craig Ringer |
---|---|
Тема | Re: Configurable location for extension .control files |
Дата | |
Msg-id | 51B7FDD0.5090803@2ndquadrant.com обсуждение исходный текст |
Ответ на | Re: Configurable location for extension .control files (Tom Dunstan <pgsql@tomd.cc>) |
Ответы |
Re: Configurable location for extension .control files
|
Список | pgsql-hackers |
On 06/12/2013 08:52 AM, Tom Dunstan wrote: > Hi Josh > > On 11 June 2013 04:37, Josh Berkus <josh@agliodbs.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
В списке pgsql-hackers по дате отправления: