I'd love to see this too. I've only used HDBC and I think it works well.
A common problem in the Haskell-community is that some produce
low-level bindings/libs and some produce high-level (extremely type
safe) bindings/libs but there's seldom good support for switching
between or combining the two approaches.
My experience is that when it comes to real world scenarios involving
databases/xml/json/&c you are seldom able to figure out *all* types
compile time and are thus forces to use the low-level lib for
everything even though you got the types (e.g. of a
table/view/function/...) at compile time for 90% of your code. That's
a shame and something that I wish a merging between the packages would
be able to solve. In other words: a good package should support more
than one way to interface with the db and the different ways should be
possible to seamlessly combine.
My wish-list:
* low level capabilities a la HDBC
* high level capabilities (matching result sets to data types, db
functions <-> haskell type classes or similar)
* sql 2003/2008-, pl/sql-quasi quoter
* code generation given a db schema.
* schema generation from code (i.e. the opposite from the above).
* fixture generation (Haskell -> db, db -> Haskell)
* syb-support
* BSD3 or DWTFYWT
* github :)
I'm prepared to spend a couple of hours a week helping out and I got
some experience developing database layers that's used in telecom,
gaming and logistics.
-- Oscar
P.S. I'm not saying that there should be only one; competition is
always good. It would however be lovely if the community made an
effort to (a) produce an package that can cover mosts needs that (b)
most developers/package-maintainers used that (c) other developers can
build upon with new features.