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

Dear Tom Lane,

Thank you for your feedback.

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.

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.

Since parseServiceFile already checks for the trailing '\n' and removes it, I think we can also check for a trailing '\r' and remove it. So, I suggest to improve the parseServiceFile function [1] to discard trailing '\r'.

I've isolated the problem, and I think the attached patch solves this issue. The added filter for '\r' has no effect if the pg_services file does not have any '\r'.

I've saw many people complaining of this tiny issue and I think it is easy to solve.

What do you think? Do you see any inconvenient in filtering '\r'?

Best regards,

Gustavo

[1] src/interfaces/libpq/fe-connect.c

PG Bug reporting form <noreply@postgresql.org> writes:

I'm using `pg_services.conf` to provide access to a Postgresql database.
...
From other's feedback, I've tried to use the line separators in
pg_services.conf with \n and \r\n, but the result is the same (because there
is strange newline after the host address).

Hm, can you double check that?  It sure looks like something is failing to
remove the "\r" from that line of pg_service.conf.  Which is odd, because
libpq opens the file in text mode so the Windows C library ought to take
care of reducing "\r\n" to "\n".

It seems like in general, maybe we ought to trim trailing spaces from
pg_service.conf entries automatically.  But I'm not entirely sure if
that would fix this problem...
			regards, tom lane

--

   Geomaster, LDA

  VENHA DESCOBRIR O CAMINHO DO OPEN SOURCE CONNOSCO