Hi Tom,
Thank you for the feedback.
Às 14:54 de 18/06/19, Tom Lane escreveu:
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.
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
--
Geomaster, LDA
VENHA DESCOBRIR O CAMINHO DO OPEN SOURCE CONNOSCO
Avenida Barros e Soares
N.º 423, 4715-214 Braga
VAT/NIF 510 906 109
Phone +351 253 680 323
Site geomaster.pt
GPS 41.53322, -8.41929 |
