Tomas Zubiri <m...@tomaszubiri.com> writes:
> The problem was that running the command psql without arguments
> returned the following
> error message:
> psql: could not connect to server: No such file or directory
> Is the server running locally and accepting
> connections on Unix domain socket "/var/run/postgresql/.s.PGSQL.5432"?
The reason this failed, most likely, is using a semi-broken installation
in which libpq has a different idea than the server of where the
unix socket should be. The right fix is one or the other of
(a) don't mix-and-match Postgres packages from different vendors,
(b) adjust the server's unix_socket_directories parameter so that
it creates a socket where your installed libpq expects to find it.
I realize that this isn't great from a newbie-experience standpoint,
but unfortunately we don't have a lot of control over varying
packager decisions about the socket location --- both the "/tmp"
and the "/var/run/postgresql" camps have valid reasons for their
choices.
I do not think your proposal would improve matters; it'd just introduce
yet another variable, ie which transport method did libpq choose.
As Christoph noted, that affects authentication behaviors, and there
are a bunch of other user-visible impacts too (SSL, timeouts, ...).
If we were going to do something of this sort, what I'd be inclined
to think about is having an option to probe both of the common socket
directory choices, rather than getting into TCP-land. But that still
might be a net negative from the standpoint of confusion vs. number of
cases it fixes.
regards, tom lane
