Improvement to psql's connection defaults - Mailing list pgsql-hackers

Hello, this week I decided to pursue an error a bit further than
usual, even after having fixed it for myself, I found that I could fix
it for future newcomers, especially those running
containerized distributions.

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"?

Now, I eventually found a way around this by specifying the host with
the following command 'psql -h localhost -p 5432'.

However, the answers I found on google didn't suggest this simple fix
at all, I found a lot of confused users either exposing the sockets
from their containers, or worse, bashing into their containers and
running psql from inside :*(
https://stackoverflow.com/questions/27673563/how-to-get-into-psql-of-a-running-postgres-container/59296176#59296176

I also found this is a common error in postgres docs:
https://www.postgresql.org/docs/9.1/server-start.html
https://www.postgresql.org/docs/10/tutorial-createdb.html


So I wondered, since psql went through the trouble of guessing my unix
socket, it could guess my hostname as well. Indeed I would later find
that the tcp defaults were already implemented on non-unix builds,
additionally psql already has a mechanism to try multiple connections.
So
my humble change is for unix builds to try to connect via unix socket,
and if that fails, to connect via localhost. This would save headaches
for newbies trying to connect for the first time.

Attached you will find my patch. Below you can find the form required
for submitting patches.

Project name: Not sure, psql?
Uniquely identifiable file name, so we can tell the difference between
your v1 and v24:
Running-psql-without-specifying-host-on-unix-systems.patch
What the patch does in a short paragraph: When psql is not supplied a
host or hostname, and connection via default socket fails, psql will
attempt to connect via default tcp, probably localhost.
Whether the patch is for discussion or for application: Application,
but further testing is required.
Which branch the patch is against: master
Whether it compiles and tests successfully, so we know nothing obvious
is broken: Compiles and works successfully in my linux machine,
however I can't test whether this works on non-unix machines, I will
need some help there. I didn't see any automated tests, hopefully I
didn't miss any.
Whether it contains any platform-specific items and if so, has it been
tested on other platforms: Yes, connection via socket is only
available on unix systems. I need help testing on other platforms.
Confirm that the patch includes regression tests to check the new
feature actually works as described.: make check runs successfully,
there seems to be a test called psql_command that confirms that psql
can connect without specifying host. But I didn't add a test for
connecting via tcp.
Include documentation on how to use the new feature, including
examples: The docs already describe the correct behaviour in
/doc/src/sgml/ref/psql-ref.sgml "If you omit the host name psql will
connect via a Unix-domain socket to a server on the local host, or via
TCP/IP to localhost on machines that don't have Unix-domain sockets."
Describe the effect your patch has on performance, if any: OS without
unix socket support still won't try to connect via unix socket so they
will be unaffected. This change should only affect paths where
connection via socket failed and the user would have been shown an
error. One could argue that, some users might suffer a slight
performance hit by not being told that they are connecting via a
subpar method, but this is a sub-tenth of a second latency difference
for local connections I believe. If this is an issue, a warning could
be added.


Thank you for time,
Tomas.