[PyGreSQL] Improvements and directions for the future

[Christoph Zwerschke]

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