Re: Improvement to psql's connection defaults

From: Christoph Moench-Tegeder <cmt(at)burggraben(dot)net>
To: Tomas Zubiri <me(at)tomaszubiri(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Improvement to psql's connection defaults
Date: 2019-12-16 13:01:00
Message-ID: 20191216130100.GB2639@elch.exwg.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

## Tomas Zubiri (me(at)tomaszubiri(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Surafel Temesgen 2019-12-16 13:23:59 Re: Conflict handling for COPY FROM
Previous Message Juan José Santamaría Flecha 2019-12-16 12:40:40 Re: Collation versions on Windows (help wanted, apply within)