Did some experiments today to get PyGreSQL running with Windows and
Python both 64 bit. As explained, this needs the libpq64 which is
included with the EnterpriseDB PostgreSQL installer now.
Luckily, it was possible to build a functional 64bit PyGreSQL driver
based on libpq64 with both Visual Studio 8 and MinGW-64.
However, I found that our setup.py file needs some serious cleanup first
and then some special casing for different compilers.
Also found the following two issues:
1) Our get_type_array() method needs some type definitions which are not
part of the libpq header file. Instead, they are included from a header
file of the PostgreSQL server (catalog/pg_type.h) which is not always
installed on client machines and indirectly imports a whole megillah of
other header files, causing various problems in the past. So I have
extracted these type definitions to a local header file that we should
ship with PyGreSQL. We are using only the basic types from there, which
should not change any more - if they do we are screwed anyway because we
should actually not take the from the client but query them from the
pg_type view on the server we are connecting to.
2) Our query and pglarge objects implement a print method (tp_print).
This yields the output of PQprint() for queries and the status and oid
for large objects, and can be helpful for debugging. But these objects
so far do not implement repr() and str(). The problem with the print
function is that it takes a pointer to a FILE structure as a parameter
and therefore does not work if there are incompatibilites between the
FILE structure of the compiler used for Python and the one used for
compiling PyGreSQL (e.g. Visual Studio 2008 and MinGW-64). [Atually we
are using a clone of the PQprint() function. If we would use the
original PQprint() function as we did in the past, then we would get the
same problem when the FILE structures of the compilers used for Python
and Postgres were different, which is not under our control.]
I think we should get rid of this problem by not using tp_print any
more, but only tp_str. This is also what is recommended in the Python
documentation: "It is possible that the tp_print field will be
deprecated. In any case, it is recommended not to define tp_print, but
instead to rely on tp_repr and tp_str for printing." Making the print
output different from str() was against the standard anyway: "A type
should never implement tp_print in a way that produces different output
than tp_repr or tp_str would." So I suggest we let str() return the same
output as we had used for printing so far, and drop tp_print.
Can I go ahead and commit my setup.py clean-ups and these 2 changes?
-- Christoph
_______________________________________________
PyGreSQL mailing list
[email protected]
http://mailman.vex.net/mailman/listinfo/pygresql
