[Haskell-cafe] HDBC's future and request for help

[John Goerzen]

Hi folks,

HDBC has been out there for quite some time now.  I wrote it initially 
to meet some specific needs, and from that perspective, it has been done 
for awhile.  It is clear, however, that there are some needs it doesn't 
meet.  Most of them relate to specific backend driver items.

I'd like to start some discussion in the community about what the future 
of HDBC and its backend drivers ought to look like.  Some models might be:

  1. I continue as maintainer for HDBC and 
HDBC-{postgresql,odbc,sqlite3} and act as patch manager/gatekeeper for 
patches that are discussed on some public mailing list.

  2. Interested parties adopt the backend drivers while I continue to 
act as maintainer/patch manager/gatekeeper for HDBC itself.

  3. Interested parties adopt all of HDBC and maintain it

I am not expressing a particular preference for any of these options; 
just putting them forth.

Here are some of the current issues I am aware of:

  1. I have no Windows development platform.  I can't test the releases 
on Windows.  Many Windows users don't have the skill to diagnose 
problems.  These problems do eventually get fixed when a Windows user 
with that skill comes along -- and I appreciate their efforts very much! 
-- but it takes longer than it ought to.

  2. The ODBC documentation is monumentally terrible, and the API is 
perhaps only majestically terrible, and it is not 100% clear to me all 
the time that I have it right.  A seasoned ODBC person would be ideal here.

  3. Issues exist with transferring binary data and BLOBs to/from at 
least PostgreSQL databases and perhaps others.  There appear to be bugs 
in the backend for this, but BLOB support in the API may need to be 
developed as well.

  4. Although the API supports optimizations for inserting many rows at 
once and precompiled queries, most backends to not yet take advantage of 
these optimization.

  5. I have received dueling patches for whether foreign imports should 
be marked "safe" or "unsafe" on various backends.  There seems to be 
disagreement in the community about this one.

  6. Many interactions with database backends take place using a String 
when a more native type could be used for efficiency.  This project may 
be rather complex given varying types of column data in a database -- 
what it expects for bound parameters and what it returns.  The API 
support is there for it though.

  7. Various other more minor items.

Thoughts?

-- John