On Mon, May 7, 2012 at 6:26 AM, Mark Wotton <span dir="ltr"><<a href="mailto:mwotton@gmail.com" target="_blank">mwotton@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
probably just a spectator here, though - I haven't implemented a database in my life...</blockquote><br>
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.<br><br>On Mon, May 7, 2012 at 10:10 AM, Torsten Grust <span dir="ltr"><<a href="mailto:torsten.grust@gmail.com" target="_blank">torsten.grust@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
We're thus living on the ``don't embed literal SQL text into<br>
your Haskell source at all'' end of the spectrum, somewhat distant<br>
from postgresql-simple and friends, I guess. Still, we're quite<br>
interested where these other efforts go.<br></blockquote><br>
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.<br>
<br>
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.<br>
<br>
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. <br><br>Best,<br>Leon<br>