Quoting Toby Thain <[EMAIL PROTECTED]>: > The Ingres driver also works this way. It's a while since I wrote > that code, but a comment in the code says that this is due to the > mismatch of Ingres API and libdbi API. libdbi offers 'random access' > to rows of a resultset, but Ingres is only able to provide the > complete resultset through its C API. libdbi is forced to buffer the > whole thing. > > I don't know how the other drivers do it. >
I guess I'll have to cite historical reasons once again. Both the MySQL and PostgreSQL client libraries provide a result handle after a successful query (available through calls to mysql_store_result() and PQexec(), respectively). You can the use built-in functions to randomly access these result sets. Apparently the client library has to do the buffering then. The sqlite/sqlite3 drivers use a convenience function provided by the sqlite client library which creates a result table similar to the one you have to create for ingres and oracle. If I used the new prepare/exec/finalize interface recommended these days for sqlite3, I'd have to loop over the rows until done, with no chance to implement random access. So from my point of view it boils down to either being efficient without random access or being convenient with performance bottlenecks. I'm afraid we can't satisfy both needs at a time, but should we implement two interfaces and let the users choose based on their project's needs? Is looping over rows the lowest common denominator that all database engines provide, and be it through a set of driver functions? regards, Markus -- Markus Hoenicka [EMAIL PROTECTED] (Spam-protected email: replace the quadrupeds with "mhoenicka") http://www.mhoenicka.de ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Libdbi-drivers-devel mailing list Libdbi-drivers-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libdbi-drivers-devel
