Re: Improvement to psql's connection defaults

## Tomas Zubiri (me@tomaszubiri.com):

> We already established that a tcp connection was subpar in terms of
> latency, we shall note then that a tcp connection is subpar in terms
> of security.

It's an entirely different thing, I'd argue. I'm not even convinced
that an error message is a bad thing: not specifying connection parameters
gives you the defaults (which are clearly documented - having the doc
maintainers enter into a SEO-contest would be expecting too much); and
if that fails, there's an error. Adding more guesswork on how to connect
to your database server will add confusion instead of reducing it.
(Where does "localhost" resolve to? Does it resolve at all? What
about IPv4 vs. IPv6? Is IP traffic allowed there? That's all stuff
which has been relevant in one way or the other while looking at existing
systems. Real world can deviate quite significantly from what one
whould expect as "sane".) I for one prefer to have clear defaults
and clear error messages in case that does not work.

>  Additionally, it's
> already possible to have this subpar connection and differing
> interface on non-unix platforms.

I think there's only one relevant platform without unix sockets
left (I'm not sure about vxWorks and other embedded systems, but
their applications rarely include full-blown database servers),
and that system has gone great lengths to include a linux subsystem -
that might tell you something.

> >(a) don't mix-and-match Postgres packages from different vendors,
> 
> Since there's a client-server architecture here, I'm assuming that
> there's compatibility between different versions of the software.

Generally speaking: yes. But compiled-in defaults may not match
(like the location of the Unix sockets) across different vendor
packages of the same version. And client tools might have a hard
time working against a newer major release of the server: the protocol
does not change (at least, it didn't for a long time, except for some
additions like SCRAM authentication), but the catalog may have changed
between major versions and the client can't get the information it
needs.

>  Consider this example, if you are away
> from home and you tell Google Maps or Uber that you want to go to your
> city, does it fail claiming that it doesn't have enough information or
> claiming that the route it would take given the subpar information you
> gave it would be subpar?

That's a good example, but not in the way you think: people and vehicles
(trucks and lorries, even) ending up some hundreds of kilometres from
their intended destination because their navigation system "tried it's
best" with an ambiguously entered name is quite a common occurence here.
(For example, there are at least six places called "Forst" and some dozens
"Neustadt" - many more if you count boroughs and similar - in Germany).

Regards,
Christoph

-- 
Spare Space