Re: [Haskell-cafe] HDBC, postgresql, bytestrings and embedded NULLs

On Mon, Jan 17, 2011 at 10:52 PM, John Goerzen wrote:

On 01/17/2011 10:07 AM, Michael Snoyman wrote:

...

On Mon, Jan 17, 2011 at 4:49 PM, Leon Smith  wrote:

...

On Sat, Jan 8, 2011 at 11:55 AM, Michael Snoyman  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