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

Hi Tom,

Thank you for the feedback.

Às 14:54 de 18/06/19, Tom Lane escreveu:

> 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.

I think it depends on the C library implementation. I've checked this discussion on SO: https://stackoverflow.com/questions/12769289/carriage-return-by-fgets

One answer is related to the C standard and another says that Microsoft compilers behave differently. So, it depends on how libpq is compiled. Does it make sense?

I found that, in Windows, after installing QGIS, which includes libpq.dll, the library does not discard '\r'. Maybe QGIS for Windows is compiled with a non Microsoft compiler. I've cc Jürgen Fischer that might provide more details.

||||

|If everybody uses the same compiler and all get the '\r' removed from
text files, I agree that we don't need to change anything. But if there
are compilers available, implementing the C standard and don't strip
automatically '\r', at least we should warn users that these compilers
can produce code with this small limitation. |

> 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.

If you check my initial QGIS bug report https://github.com/qgis/QGIS/issues/30027 there is *something* in front of the host address:

|psycopg2.OperationalError: could not translate host name "192.168.1.24
" to address: Unknown host|

You can see replies related to the '\r' issue.

1) https://github.com/qgis/QGIS/issues/30027#issuecomment-497433789

2) https://github.com/qgis/QGIS/issues/30027#issuecomment-498690261

3) https://github.com/qgis/QGIS/issues/30027#issuecomment-498700090

4) https://github.com/qgis/QGIS/issues/30027#issuecomment-501799219

I didn't invented the '\r' problem. I've just jumped into it.

I didn't found any other issue with line endings problems in Postgresql. Maybe other '\r' are not harmful. But these in front of host names or host addresses are critical to resolve the ip addresses.

But, for the sake of clarity, the summary is this:

Installing QGIS, in Windows, with libpq, if the pg_services.conf file has '\r\n' line endings, the pg_services fails.

Installing QGIS, in Windows, with libpq, if the pg_services.conf file only has '\n' line endings, the pg_services rocks!

> regards, tom lane
>
--

Logo*   Geomaster, LDA*

  *VENHA DESCOBRIR O CAMINHO DO OPEN SOURCE CONNOSC**O *

  Avenida Barros e Soares N.º 423, 4715-214 Braga VAT/NIF510 906 109
Phone  +351 253 680 323 Site       geomaster.pt <http://geomaster.pt>
GPS       41.53322, -8.41929

------------------------------------------------------------------------

  Jorge Gustavo Rocha CTO Mobile  +351 910 333 888 Email    jgr(at)geomaster(dot)pt