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

[Michael Snoyman]

On Mon, Jan 17, 2011 at 10:52 PM, John Goerzen <jgoerzen at 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.smith at gmail.com>
>>  wrote:
>>>
>>> On Sat, Jan 8, 2011 at 11:55 AM, Michael Snoyman<michael at 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