Database interface - would like advice on oracle library bind ing

Bayley, Alistair Alistair_Bayley at
Wed Sep 24 11:44:16 EDT 2003

> From: oleg at [mailto:oleg at]
> I'd like to remark first that many real databases let us avoid opening
> many cursors at once. It seems to be more efficient to do as much as
> possible within the engine ...

I agree (and Tom Pledger makes the same comment). It's rare that I want to
have more than one cursor open at once. When I've seen other developers do
it, they're often doing something that would be better accomplished as a
join. And that last time I remember doing it, it was a nested loops
situation (which, on reflection, probably could have been done as a join...
oh well).

OTOH, I have seen interleaved fetches used to simulate a join where the
specific DBMS product struggled to perform the join efficiently itself. In
this case the developer is making up for a deficiency in the DBMS, and I
don't want to exclude the option from the interface (if you agree with what
you read on , then most DBMS products are deficient
in a number of ways).

> Still, opening several cursors may be unavoidable. The left fold
> approach may still help -- we _can_ mechanically invert a left fold
> combinator (to be precise, a half-baked version of it) into a lazy
> list. Please see a separate message "how to invert the left fold"

Found it. I'll have a look...

> I believe the extract functions can be constructed automatically --
> similar to the way Quickcheck constructs test cases. I believe that
> instead of

I though this might be possible, but I had no idea how to do it. I'll have a
look at the Quickcheck source to see how it's done, unless you can suggest a
better example.

> buffers. It's hard for me to write the corresponding code because I
> don't have Oracle handy (besides, I like Informix better). Is it
> possible to come up with a "stub" that uses flat files? We are only
> interested in fetching rows. It doesn't matter if these rows come from
> a file or from a database. That would make prototyping the interface 
> quite easier.

I wasn't interested so much in prototyping the interface, as trying to write
an implementation that supported the interface(s) discussed previously. I
intended to provide the left-fold interface, and was wondering if that was
all that was needed (for selects). Still, this would be a good exercise for
me, at least so I can figure out how to generate extraction functions.

> From: Tom Pledger [mailto:Tom.Pledger at]

> Here's one approach: find the OCI equivalent of JDBC's
> ResultSetMetaData, and use it to drive the allocation and freeing of
> buffers.

I've considered this, and I think it's the next route I'll take (the OCI
supports it). At the least it'll give me the ability to perform arbitrary
queries (at present I have to know the types of the result set columns and
construct the extraction function manually).

I've also considered stuffing more information into the Cursor type (which
I've introduced), and using this in a modal fashion to decide what to do at
each point.

> Here's another: ...
>     Make getInt (and friends) behave differently depending on the mode
>     of the cursor they're passed: either allocate a buffer and return
>     _|_, decode and return the current column of the current row, or
>     free a buffer and return _|_.

Not wanting to sound too dumb, but how do you return _|_ ?


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.

More information about the Haskell-Cafe mailing list