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

Hi Tom,

Jorge Gustavo Rocha <jgr@geomaster.pt> writes:

The error I was facing in QGIS is because the application changes the
default fopen mode to binary mode. So, every file is opened in binary
mode and so is pg_services.conf.

Ah-hah!  That explains much.  So a non-invasive fix would be to force
parseServiceFile to open the file in text mode; I think this would
work for that:

-	f = fopen(serviceFile, "r");
+	f = fopen(serviceFile, "rt");

I've wrote a small test program in Windows, using MSVS, and your fix works as expected. Even if we set the global mode to binary, if the file is opened with "rt", the file is opened in text mode and \r are discarded. Good!

I've attached the C file and one pg_services.conf file with \r, just for the record.

This fixes the problem in QGIS.

I don't think that that's really a good solution, because it does little
to prevent the same problem from reappearing elsewhere.  But if we wanted
the smallest possible fix that might do.

In my humble opinion, we could make pg_services.conf agnostic in terms
of \r, just by filtering them, if present.

I think we should have it go further and ignore any trailing isspace()
characters, so that trailing spaces don't cause problems either.
But in any case, the real stumbling block here is to get a project-wide
convention as to how to do it.

Probably this can be accomplish by using a common function to read all these kind of files. The function handles the text tokenize/parsing and provided the contents in higher level data structure.

For example, OpenSceneGraph provides wrappers for all functions related to the file system and to read and write all kind of file formats [1]. Developers can use things like readImageFile, readShaderFile, readXmlFile, etc, without caring about os type, character encoding, etc.

If you point me some more examples where we need to read such files in Postgresql, I can think about a proposal to handle all these cases.

But since we are discussing just a small tiny fix, if you agree, we could apply this fix and later think about a common approach to handle all text parse needed in different parts of the code. Is this fair?

Regards,

Jorge Gustavo

[1] http://public.vrac.iastate.edu/vancegroup/docs/OpenSceneGraphReferenceDocs-3.0/a01245.html#a27021fc08b8d4088a72e83b81d771481

			regards, tom lane

--

   Geomaster, LDA

  VENHA DESCOBRIR O CAMINHO DO OPEN SOURCE CONNOSCO