FYI... It looks like I'm going to be getting some consultancy work that'll include making some changes to the DBI. Almost all relate to squeezing extra performance out of the DBI.
Here's a summary of what I plan to do: 1/ Move the implementation of selectrow_arrayref() into C code. Both within the DBI.xs as a fallback method for Perl drivers, and within the Driver.xst 'driver wrapper' that's 'underneath' the DBI API. This would provide performance gains both from being implemented in C and, for Driver.xst, by avoiding extra calls through the DBI, 2/ Move fetchall_arrayref implementation to C, both within the DBI and the Driver.xst code. The Driver.xst code implementation will make fetchall_arrayref *very* *very* fast. (If it's called with params requesting a hash slice it'll fallback to a perl code implementation.) 3/ I'm thinking of changing the spec of selectrow_arrayref slightly such that it won't call finish() *if* it has been passed a prepared statement handle. The idea being that if you've passed selectrow_arrayref a prepared statement handle then the chances are you'll be calling selectrow_arrayref with that handle again and so the finish is not required. Since the app must have called prepare() it's not unreasonable for it to also call finish(). 4/ Add the ability to fetch a subset of rows in a single call. I'm thinking in terms of adding a parameter to fetchall_arrayref to request that only N rows be fetched. I'm also thinking of adding a parameter to pass in a reference to any array onto which you'd like the new rows pushed. 5/ Enable the DBI to optionally gather performance statistics. The new functionality will be implemented in C for maximum performance. It'll also be simple to enable and disable and while disabled will have as near to zero overhead as possible. I'm not sure of the details yet but at the very least it'll give you a hash of the time spent executing each distinct sql statement and the time spent in each method call and an overall total. More news on this when I've though some more about it. 6/ The new HandleError interface will be polished up and stabilized. (Note that a particularly handy aspect of HandleError is that the code executes in the context of the DBI call that triggered the error. Thus it's possible to do things like get a stack trace. I don't think I ever pointed that out before.) 7/ Add an API to ask drivers to return the value of a placeholder. 8/ Add calls to that API into the PrintError/RaiseError code so that when ShowErrorStatement is true the error message will include the placeholder values. Tim.
