On 06/12/2013 02:24 PM, Tom Dunstan wrote: > On 12 June 2013 14:19, Craig Ringer <cr...@2ndquadrant.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.
Yes, they do - including a horde of deeply confused and frustrated Rails users struggling to understand why they're getting "no such file or directory" or "permission denied" messages about Pg's unix socket, because of course they're linked to Apple's libpq which has a different default unix socket path, and unless they explicitly specify `host: localhost` in their Rails database.yml they get a unix socket connection. I only know this because it comes up so much on SO; I don't use Rails (or a Mac) myself. It's clearly a real pain point for new users, though. This is one of the more commonly referenced examples, but there are a few more every week: http://stackoverflow.com/q/6770649/398670 > 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? Good point ... requiring an explicit `pg_config` to be specified would help a lot. Another option would be to have to explicitly allow use of Apple's PostgreSQL (based on known install paths) though; think "--use-system-postgresql". I'm sure the Ruby Pg gem folks have discussed this but I've seen no sign of any improvement. > 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? Only at runtime, when they try to connect (see above link for one example). > 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. An interesting idea. Unfortunately, many of these people *also* install PostgreSQL from homebrew or have used it in the past. Don't ask me why, but it seems common going by SO questions etc. I think they have a problem with Homebrew so rather than try to fix it they just try installing postgres.app instead, or vice versa. Anyway, point being that PostgreSQL from Macports, Homebrew, and/or EnterpriseDB's installer might be present ... and even in use. I get the strong impression from what I've been reading that a fairly typical Rails user setup is: * Install homebrew * Install PostgreSQL using homebrew but don't start it * Build the Pg gem against homebrew postgresql's libpq * Download and run postgres.app * Run your Pg gem using the libpq from homebrew against the postgres.app server Ugh. > 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. Good point... though that also raises more concerns regarding consumers of the Pg library. And extensions, for that matter; if extensions are out-of-tree you need versioned subdirectories, otherwise you'll have conflicts between 9.2 and 9.3 (for example) versions of the same extensions. It's also another issue with libpq. User upgrades Postgres.app and suddenly their Ruby gems stop working with some linkage error they probably don't understand. (All this is, IMO, really a lesson in why Apple should introduce a non-awful packaging system into OS X). -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
