[Haskell-cafe] HDBC, postgresql, bytestrings and embedded NULLs
michael at snoyman.com
Mon Jan 17 22:16:09 CET 2011
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>
>>> On Sat, Jan 8, 2011 at 11:55 AM, Michael Snoyman<michael at snoyman.com>
>>>> 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:
>>> 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
>> 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 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.
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.
More information about the Haskell-Cafe