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

From Christoph Moench-Tegeder
Subject Re: Improvement to psql's connection defaults
Date
Msg-id 20191216130100.GB2639@elch.exwg.net
Whole thread Raw
In response to Improvement to psql's connection defaults  (Tomas Zubiri <me@tomaszubiri.com>)
List pgsql-hackers
## Tomas Zubiri (me@tomaszubiri.com):

> The problem was that running the command psql without arguments

There's an excellent manpage for psql, which can also be found online:
https://www.postgresql.org/docs/current/app-psql.html

In there you'll find a section "Connecting to a Database", with the
following sentences:
: In order to connect to a database you need to know the name of your
: target database, the host name and port number of the server, and what
: user name you want to connect as.  psql can be told about those parameters
: via command line options, namely -d, -h, -p, and -U respectively.

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

I'm a little confused as to why people don't read the documentation and
turn to the 'net - that's bound to dig up a lot of people who haven't
read the docs, too.

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

I'd thing that opens a can of worms:
- authentication options for TCP connections, even on localhost, are
  often different from those for Unix-domain sockets (e.g. while
  using peer authentication for administration purposes might make
  a lot of sense, TCP connections need some credential-based authentication
  so "any rogue process" cannot simply connect to your database).
- Do we have any guarantees that these containers always expose the
  PostgreSQL server on what the host thinks is "localhost:5432"? I'm
  thinking of network namespaces, dedicated container network interfaces
  and all the other shenanigans. And what about the use cases of "more
  than one container" and "database on the host and in a container"?
  My concers is that adding more "magic" into the connection logic
  will result in more confusion instead of less - the distinction
  between the "default case Unix-domain socket" and "TCP" will be lost.

Regards,
Christoph

-- 
Spare Space



pgsql-hackers by date:

Previous
From: Juan José Santamaría Flecha
Date:
Subject: Re: Collation versions on Windows (help wanted, apply within)
Next
From: Surafel Temesgen
Date:
Subject: Re: Conflict handling for COPY FROM