Robert Haas <robertmhaas@gmail.com> writes:
> On Thu, Aug 9, 2018 at 11:44 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> So I think we should basically s/printfPQExpBuffer/appendPQExpBuffer/g
>> anywhere those files touch conn->errorMessage, allowing any problems
>> with previous servers to be preserved in the eventually-reported message.
> I guess the question in my mind is what behavior is most useful for
> users. There are, I'm sure, cases where it's useful to see all the
> details you are proposing to print. But it also seems like there
> could be a significant number of cases where it's really more than
> anybody wants to know. For instance, if I try to connect
> host=primary1,primary2,dr and primary1 is offline right now, because
> we're using primary2, and if it happens that I mistype my password,
> with your patch, I'll get an error saying that primary1 is down,
> followed by an error about my password. I only care about the second
> one. If I had typed my password correctly, I would have just gotten a
> connection, and everything would have been fine. Telling me that
> primary1 is down may make me (1) panic or (2) miss the real cause of
> my problem.
> So I'm not as convinced as you are that always displaying maximum
> detail is really the right thing to do.
Well, I'm actually not proposing to print "maximum detail", and Fabien
is complaining about that, which makes me think maybe I've hit a happy
medium ;-). In particular, the proposed patches won't change behavior
for cases where you just give one hostname or hostaddr, and I'd argue
that that is the only case where we really have enough track record to
be sure that people are happy with the amount of detail provided.
As soon as you have multiple target hosts, though, the current code's
behavior is inadequate IMO. Indisputably it's inconsistent, because
some code paths will concatenate error messages and some won't, without
any rhyme or reason that I can detect. I think the only reason we've
not had more complaints is that hardly anyone is using this feature yet.
regards, tom lane
