On Mon, May 7, 2012 at 6:26 AM, Mark Wotton
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
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