On Mon, Jan 17, 2011 at 10:52 PM, John Goerzen <jgoer...@complete.org> wrote: > On 01/17/2011 10:07 AM, Michael Snoyman wrote: >> >> On Mon, Jan 17, 2011 at 4:49 PM, Leon Smith<leon.p.sm...@gmail.com> >> wrote: >>> >>> On Sat, Jan 8, 2011 at 11:55 AM, Michael Snoyman<mich...@snoyman.com> >>> wrote: >>> >>>> In general I think it would be a good thing to have solid, low-level >>>> bindings to PostgreSQL. >>> >>> Well, there is PostgreSQL and libpq on hackage: >>> >>> http://hackage.haskell.org/package/libpq >>> http://hackage.haskell.org/package/PostgreSQL >>> >>> The PostgreSQL looks like it's in need of maintenance, and hasn't >>> been updated in a few years. libpq is new, and looks promising. I >>> haven't really used either one, so I can't really say too much about >>> either. >>> >>> Best, >>> Leon >>> >> >> I've tried PostgreSQL before, and if I remember correctly I couldn't >> even build it. libpq looks interesting, I'd like to try it out. >> Unfortunately it depends on unix, which would be a problem for Windows >> users. If it looks like a good fit for persistent-postgresql, maybe I >> can convince the author to replace the unix dep with something else >> (unix-compat might be sufficient). > > I would also like to know what things people find are deficient in HDBC or > HDBC-postgresql. If the API isn't good enough for some uses, that could be > fixed. I would like to avoid a proliferation of database libraries as that > is unnecessary duplication of work. HDBC does have an easy way for DB > backends to implement more functionality than the HDBC API supports, or an > alternative could also be to make HDBC-postgresql a thin binding over libpq > or some such.
I've brought up before my problem with the convertible package: it encourages usage of partial functions. I would prefer two typeclasses, one for guaranteed conversions and one for conversions which may fail. In fact, that is precisely why convertible-text[1] exists. As a related issue, there are a large number of data constructors in HDBC for SqlValue. I would not argue with the presence of any of them: for your purposes, every one of them is necessary. But for someone writing a cross-backend package with a more limited set of datatypes, it gets to be a problem. I know I can use convertible for this, but see my previous paragraph ;). I also don't like using the lazy result functions. I'm sure for many people, they are precisely what is needed. However, in my applications, I try to avoid it whenever possible. I've had bugs crop up because I accidently used the lazy instead of strict version of a function. I would prefer using an interface that uses enumerators[2]. For none of these do I actually think that HDBC should change. I think it is a great library with a well-thought-out API. All I'm saying is that I doubt there will ever be a single high-level API that will suit everyone's need, and I see a huge amount of value in splitting out the low-level code into a separate package. That way, *everyone* can share that code together, *everyone* can find the bugs in it, and *everyone* can benefit from improvements. Michael [1] http://hackage.haskell.org/package/convertible-text [2] http://hackage.haskell.org/package/enumerator _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe