[Haskell-cafe] Haskell not ready for Foo [was: Re: Hypothetical Haskell job in New York]

Manlio Perillo manlio_perillo at libero.it
Thu Jan 15 13:31:41 EST 2009

John Goerzen ha scritto:

>> Python has pure interfaces to all the major databases. While it's true  
>> there are no "native" GUI libraries, there are pure Python libraries for 
>> just about everything else. Haskell is not yet to this point.
> By "pure" do you mean "containing python code only"?  I'm looking
> through a few, and:
> PostgreSQL - psycopg - C
> PostgreSQL - pgsql - C
> PostgreSQL - pygresql - C
> MySQL - mysqldb - C
> MS SQL Server - pymssql - C
> And any interface that uses ODBC will, by necessity, be calling to C,
> because ODBC is defined as a C API and not a network protocol.
> Where are all these pure-Python drivers?

Time ago, I implemented a client for the network protocol used by 

it covers almost all the protocol features (only extended queries are 
not supported).

It is implemented using Twisted.
I would like to reimplement it in Haskell, sometime in the future.

I tried to implement the MySQL network protocol, too, but it is a 
*mess*, so I gave up (and, at that time, there were strange claims about 

It is also possible to support MSSQL and Sybase, implementing a client 
for the TDS (Tabular Data Stream) protocol.

TDS, too, is a mess (well, if you compare it with the PostgreSQL 
protocol), and last time I studied it, the freeTDS project only had a 
reversed engineered protocol documentation; now Microsoft has made the 
TDS variant used my MSSQL public:

So, in theory, it should not really be a problem to implement native and 
robust support for PostgreSQL, MySQL, MSSQL and Sybase.

One benefit of these implementation would be builtin support to 
concurrency [1].
For PostgreSQL, a native implementation can be useful to listen notifies.

 > [...]

[1] the libpq API *has* support for async API, but it is not
     complete (and well tested like sync API, IMHO).
     As an example there is no support for async function call, although

     "The Function Call sub-protocol is a legacy feature that is 
probably best avoided in new code. Similar results can be accomplished 
by setting up a prepared statement that does SELECT function($1, ...). 
The Function Call cycle can then be replaced with Bind/Execute."

P.S.: the PostgreSQL protocol is really well designed

Regards  Manlio Perillo

More information about the Haskell-Cafe mailing list