Database interface

[Bayley, Alistair]

> From: Thomas L. Bevan [mailto:thomas_bevan@toll.com.au]
> 
> Ideally, we would have the following.
> 
> 1/ A high level combinator library for relational calculus built on,
> 
> 2/ A standard low-level Haskell API 
>  i.e. functions like Connection -> String -> ( a -> b -> IO b) -> IO b
> 
> 3/ Database specific bindings.
> 
> The problem is that projections and cartesian products 
> generate new types, at 
> least in the way it was done in HaskellDB. The form the 
> calculus takes would 
> need to be substantially reworked.

I don't see why the generation of new types would cause a problem. Can't we
get the calculus library to generate the extraction function at the same
time, so that it returns rows of the appropriate type? The generated
extraction function would have to be built from standard extraction
functions exposed by the low-level API. Although, would this limit the set
of types you could use to just those in the low-level API?


*****************************************************************
The information in this email and in any attachments is 
confidential and intended solely for the attention and use 
of the named addressee(s). This information may be 
subject to legal professional or other privilege or may 
otherwise be protected by work product immunity or other 
legal rules.  It must not be disclosed to any person without 
our authority.

If you are not the intended recipient, or a person 
responsible for delivering it to the intended recipient, you 
are not authorised to and must not disclose, copy, 
distribute, or retain this message or any part of it.
*****************************************************************