On Mon, May 7, 2012 at 6:26 AM, Mark Wotton <mwotton@gmail.com> wrote:
probably just a spectator here, though - I haven't implemented a database in my life...
I've never implemented a database engine either, and I suspect that
describes a majority of the people here. My wish for a relational
alternative to SQL is just that: a wish. It seems to me that this
list is likely to be far more focused on interacting with existing
database engines, like HDBC, *-simple, persistent, DSH, and the
like.
On Mon, May 7, 2012 at 10:10 AM, Torsten Grust <torsten.grust@gmail.com> wrote:
We're thus living on the ``don't embed literal SQL text into
your Haskell source at all'' end of the spectrum, somewhat distant
from postgresql-simple and friends, I guess. Still, we're quite
interested where these other efforts go.
Well, I don't think embedded SQL is entirely bad, but I don't think
embedded SQL as particularly desirable either; I see DSH as basically a
higher-level layer on top of postgresql-simple and friends. It's just
that I'm mucking around in lower-level details right now, trying to get
those halfway right, so that DSH can be that much better.
Also, it seems to me that the benefits of database-specific features
tend to outweigh trying to be database-independent; the least common
denominator seems terribly constraining, and even the SQL standard is often
not implemented consistently. So one generic concern is that a
higher-level abstraction doesn't get in the way of correct, often
database-dependent SQL. But I haven't played with DSH, so I would
emphasize that this is a _generic_ concern.
So I'm basically working at the problem from the opposite direction:
looking at the low-level interfaces and the pain points that they cause
and trying to improve those. Another obvious problem is failing
faster: it'd be really nice to have syntax checking and end-to-end
typechecking; although this can't always be done 100% statically because there are reasons to use dynamically-generated SQL.
Best,
Leon