[database-devel] Welcome to database-devel!
leon.p.smith at gmail.com
Mon May 7 22:54:17 CEST 2012
On Mon, May 7, 2012 at 6:26 AM, Mark Wotton <mwotton at 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 at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the database-devel