Robert Haas <robertmhaas@gmail.com> writes:
> On Wed, Aug 15, 2018 at 12:05 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> TBH I find your example to be the exact opposite of convincing.
> That seems like a pretty unlikely use case, though. It seems to me
> that the virtue of the feature is in letting you connect to one of a
> number of hosts that are basically all equivalent. If they're not all
> equivalent, how come you're OK with connecting to any one of them?
I'm still unpersuaded. The point you're ignoring is that the *intention*
might be that the hosts are equivalent, but the *reality* might be that
they're not, and the difference very likely is exactly why your connection
failed. Password not what you expected, user or database not there at
all, etc. In such situations, an error message that doesn't give you
enough info to realize where the problem really lies is very unfriendly.
Also, if I buy this line of argument, I fail to see why the existing
messages that explicitly mention which host we didn't connect to (because
of problems with the read-write session test) are like that. How is it
that those need to be labeled as to host, and concatenated, but other
sorts of failures don't? I think the author(s) of that patch understood
the problem perfectly well, but were too lazy or cowardly to fix it other
than in code they were adding. I'm here to clean that up.
> In a perfect world where users never misinterpret error messages, they
> wouldn't, but that is not a world I have the privilege of inhabiting.
Me neither, but a message that fails to provide critical context
is much more susceptible to misinterpretation than one that doesn't.
regards, tom lane
