Re: BUG #15827: Unable to connect on Windows using pg_services.conf using Python psycopg2

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>
To: Jorge Gustavo Rocha <jgr@geomaster.pt>
Cc: pgsql-bugs@lists.postgresql.org
Date: 2019-06-18T13:54:45Z
Lists: pgsql-bugs
Jorge Gustavo Rocha <jgr@geomaster.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



Commits

  1. Fix failures to ignore \r when reading Windows-style newlines.