Re: Configurable location for extension .control files

On 12 June 2013 14:19, Craig Ringer <craig(at)2ndquadrant(dot)com> wrote:

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

Oh, interesting. Do the ruby/rails folks use that rather than a pure-ruby
driver? I guess I'm spoiled - most of my development happens on the JVM,
and the JDBC driver doesn't use libpq.

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

Hmm, so what might a sane solution look like? It looks like the proper way
to build the pg gem is to specify the full path to pg_config. Maybe we
could convince the pg gem authors to error out if the found version of
postgresql is too old? I presume that we only discover the problems when
someone tries to actually use the driver - or do we find out at gem
installation time?

Another alternative is for the Postgres.app to add its bin dir to the
user's (or system's) path on first startup. Then the correct pg_config will
be found (and the correct psql, pgdump etc etc as well). The app could in
theory even go looking for existing pg gem installed under .rvm or whatever
and prompt the user to reinstall the gem.

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

They can do either of those, but if they then upgrade the app, I presume
that the extensions will disappear, and they'll need to rebuild or
reinstall them, which is a bit of a pain.

Cheers

Tom