Standard DBI Proposal (was: Re: Standard Database Interface?)

Sean Woods wrote:
There are a couple of "flexibities" that sqlite has that other
db interfaces cannot share by virtue of the fact it lives in the
same memory as the interpreter. This is not insurmountable, but
I'm thinking operations like evaluating a result to a script would
require a bit of caching by the interpreter.

That's pretty easy to work around. Just keep a per-connection array
that maps from the SQL string to whatever kind of compiled form you
want. As long as people are using SQL in the form of some type of
prepared statement (which I'd say MUST be supported) then it's pretty
simple to do. That also gives you a spot to hang off any complex
information (like whether this statement returns a value or not, for
DBs that care). At the script level, the differences must be
concealed. The way in which the back-ends achieve this, well, that's a
great topic for ingenuity... :-)

So, choosing what actually should be in there as methods...

$conn close
$conn complete
$conn eval
$conn exists
$conn transaction
$conn version

All with the SQLite semantics (modulo how they treat column types, of
course). This is a subset of the SQLite set, and should be all the
bits that are needed for most DB work (plus a few things that make
life a little easier).

Comments?

Donal.

.