On Mon, May 3, 2021 at 6:08 AM Peter Eisentraut <peter.eisentr...@enterprisedb.com> wrote: > I find these new error messages to be more distracting than before in > some cases. For example: > > PG13: > > clusterdb: error: could not connect to database typo: FATAL: database > "typo" does not exist > > PG14: > > clusterdb: error: connection to server on socket "/tmp/.s.PGSQL.65432" > failed: FATAL: database "typo" does not exist > > Throwing the socket address in there seems a bit distracting and > misleading, and it also pushes off the actual information very far to > the end. (Also, in some cases the socket path is very long, making the > actual information even harder to find.) By the time you get to this > error, you have already connected, so mentioning the server address > seems secondary at best.
It feels a little counterintuitive to me too but I am nevertheless inclined to believe that it's an improvement. When multi-host connection strings are used, the server address may not be clear. In fact, even when they're not, it may not be clear to a new user that socket communication is used, and it may not be clear where the socket is located. New users may not even realize that there's a socket involved; I certainly didn't know that for quite a while. It's a lot harder for the database name to be unclear, because since a particular connection attempt will never try more than one, and also because when it's relevant to understanding why the connection failed, the server will hopefully include it in the message string anyway, as here. So the PG13 message is really kind of silly: it tells us the same thing twice, which we must already know, instead of telling us something that we might not know. It might be more intuitive in some ways if the socket information were demoted to the end of the message, but I think we'd lose more than we gained. The standard way of reporting someone else's error is basically "what i have to say about the problem: %s" and that's exactly what we're doing here. We could find some way of gluing the information about the socket onto the end of the server message, but it seems unclear how to do that in a way that looks natural, and it would depart from our usual practice. So even though I also find this to be a bit distracting, I think we should just live with it, because everything else seems worse. -- Robert Haas EDB: http://www.enterprisedb.com
