On Tue, Aug 14, 2018 at 02:17:09PM +0200, Fabien COELHO wrote:
> I think that people would survive having the ip spelled out on localhost
> errors when there are several ips associated to the name.
>
> You could also create an exception for "localhost" if you see it as a large
> problem, but if so
On Wed, Aug 15, 2018 at 12:46 PM, Tom Lane wrote:
> 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 think this is an ad hominum attack.
I have explained some factors that are relevant fr
Robert Haas writes:
> On Wed, Aug 15, 2018 at 12:05 PM, Tom Lane 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 host
On Wed, Aug 15, 2018 at 12:05 PM, Tom Lane wrote:
> TBH I find your example to be the exact opposite of convincing.
> You've cherry-picked a case where the current behavior tells you
> what you need to know and not anything you don't, but very small
> variations on the case make that not hold anym
Robert Haas writes:
> On Wed, Aug 15, 2018 at 11:53 AM, Tom Lane wrote:
>> As soon as you have multiple target hosts, though, the current code's
>> behavior is inadequate IMO.
> I'm not entirely convinced; see the example I posted before.
TBH I find your example to be the exact opposite of conv
On Wed, Aug 15, 2018 at 11:53 AM, Tom Lane wrote:
> 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 gi
Robert Haas writes:
> On Thu, Aug 9, 2018 at 11:44 AM, Tom Lane 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.
>
On Thu, Aug 9, 2018 at 11:44 AM, Tom Lane wrote:
> I noticed that, although most error reports during libpq's connection
> setup code append to conn->errorMessage, the ones in fe-auth.c and
> fe-auth-scram.c don't: they're all printfPQExpBuffer() not
> appendPQExpBuffer(). This seems wrong to me.
Hello Tom,
The thing is that there are a *lot* of systems nowadays on which localhost
maps to both ipv4 and ipv6, so that "host=localhost" would be enough to
trigger the new behavior,
I think that people would survive having the ip spelled out on localhost
errors when there are several ips
Fabien COELHO writes:
>> As I explained in my comments, the reason I did not do these things
>> is that I didn't want to change the output for cases in which just a
>> single host name is given. I still don't.
> Ok, I get your argument when there is just one target server (cluster),
> which is
Hello Tom,
ISTM that both the hostname and ip should be shown to avoid confusion
about hosts with multiple ips, esp. as ips are given in any order by the
dns.
...
Also for homogeneity, I'd suggest to always add the server line. If the
server introduction is inserted in all cases, including whe
Fabien COELHO writes:
> ISTM that both the hostname and ip should be shown to avoid confusion
> about hosts with multiple ips, esp. as ips are given in any order by the
> dns.
> ...
> Also for homogeneity, I'd suggest to always add the server line. If the
> server introduction is inserted in al
Hello Tom,
Some points for discussion and review:
1. The bulk of patch 0001 is indeed just
s/printfPQExpBuffer/appendPQExpBuffer/g, though I also made an attempt
to use appendPQExpBufferStr wherever possible. There are two categories
of printfPQExpBuffer calls I didn't change:
1a. Calls
Michael Paquier writes:
> On Thu, Aug 09, 2018 at 11:44:27AM -0400, Tom Lane wrote:
>> I noticed that, although most error reports during libpq's connection
>> setup code append to conn->errorMessage, the ones in fe-auth.c and
>> fe-auth-scram.c don't: they're all printfPQExpBuffer() not
>> appen
On Thu, Aug 09, 2018 at 11:44:27AM -0400, Tom Lane wrote:
> I noticed that, although most error reports during libpq's connection
> setup code append to conn->errorMessage, the ones in fe-auth.c and
> fe-auth-scram.c don't: they're all printfPQExpBuffer() not
> appendPQExpBuffer(). This seems wro
15 matches
Mail list logo
