## Tomas Zubiri (m...@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
