Re: Configurable location for extension .control files

Craig Ringer <craig(at)2ndquadrant(dot)com> writes:
> On 06/12/2013 02:24 PM, Tom Dunstan wrote:
>> 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 poked at this a little bit, wondering whether it'd be practical to fix
the problem by configuring third-party postmasters to create a socket
where Apple's libpq is expecting. However, it looks like (in Lion
anyway) what libpq is expecting is this:

$ /usr/bin/psql -l
psql: could not connect to server: Permission denied
Is the server running locally and accepting
connections on Unix domain socket "/var/pgsql_socket/.s.PGSQL.5432"?

and that directory is configured with no public permissions at all:

$ ls -ld /var/pgsql_socket
drwxr-x--- 2 _postgres _postgres 68 Jun 13 2011 /var/pgsql_socket/

which basically means that no third-party code should ever be expecting
to communicate with a postmaster through there.

This being the case, I wonder if the Ruby PG gem shouldn't be written
to override the default socket location, which it could do with
something like

if (getenv("PGHOST") == NULL)
putenv("PGHOST=/tmp");

without needing to muck with interpretation of connection strings.
Of course, if third-party packagings of PG aren't consistent about
where they think the socket goes, we won't know what to put there...

regards, tom lane