From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Jorge Gustavo Rocha <jgr(at)geomaster(dot)pt> |
Cc: | pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: BUG #15827: Unable to connect on Windows using pg_services.conf using Python psycopg2 |
Date: | 2019-06-18 13:54:45 |
Message-ID: | 1473.1560866085@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Jorge Gustavo Rocha <jgr(at)geomaster(dot)pt> writes:
> The '\r' on pg_services.conf is causing problems on Windows. The
> parseServiceFile function returns the host or hostaddr with a trialing
> '\r'. Subsequent attempts to turn that into an address will fail.
So it would seem.
> I've checked the code, and parseServiceFile uses the standard C fgets
> library function. Since fgets copies all characters until '\n'
> (including the '\n'), the resulting line (right now) preserves the '\r'
> at the end, on Windows.
Well, that's exactly the question at issue: doesn't Windows' fgets()
convert \r\n to just \n? I should think that it generally does, because
we have a *lot* of fgets() calls and a quick scan says that the majority
of them aren't taking care to get rid of \r. If you can convince me that
this is actually a behavior seen in the wild, we're going to need to
change way more places than just this one.
Googling for this didn't provide a lot of insight, although I did find
one person speculating that if you used GNU glibc on Windows it would not
strip \r. That seems unlikely though.
Another possibility is that you're on a Unix machine but you're wishing
libpq would deal with a service file that has Windows-style newlines.
Anyway, I want some clarity about what's really happening here, because
I'm disinclined to touch several dozen call sites on the basis of
speculation.
> I've saw many people complaining of this tiny issue and I think it is
> easy to solve.
Nobody else has complained of this that I've heard of. Please let's
deal in verifiable facts.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Munro | 2019-06-18 13:56:40 | Re: BUG #15857: Parallel Hash Join makes join instead of exists |
Previous Message | Joao Ferreira | 2019-06-18 13:47:05 | Re: Querying foreign table with SP-GiST index results in “ERROR: cache lookup failed for type 0” |