On Tue, Jul 20, 2010 at 09:46:42PM +0100, Martin J. Evans wrote: > [...] > > As a result of the above, I don't see any way of supporting the existing > blob_read in DBI and as it is undocumented anyway and no DBDs seem to > use it
Feel free to mark it deprecated in the DBI docs.. > I've put a test implementation together as: > > odbc_lob_read(sth, colno, buf, length, \%attrs) > > where \%attrs can contain TYPE => SQL_type. > I appreciate this RFC is quite long and I'm guessing few people will get > to the end. Increasingly, I'm working with several DBDs and the > differences between them (beyond SQL differences) is proving VERY > frustrating. It would be nice to try and sort out lob reading and whilst > I'm on a roll, SQLMoreResults/more_results, last_insert_id, lob_write, > binding with a specific type etc but I guess since some of these have > been covered before and we didn't get too far in the past that perhaps > there is not a lot of interest in it. I'd like to fit DBD::ODBC with > DBI's blob_read but I don't think it works for DBD::ODBC as it stands > and I note other DBDs have provided their own lob reading methods > substantially different so I'm guessing they found that too. I encourage driver authors to implement a 'natural' private API first before working together to agree on a common API for the DBI. (The blob_read API is an example of what happens when the DBI specifies things before drivers support them.) > With Perl 6 perhaps on the horizon and Tim's current interest in JDBC I > think we are well advised to sort some of this out in Perl 5 first. It > makes little difference to me right now as I'll implement what I need > now and move on but I'm prepared to work to a DBI interface for the > common goal. Some of this is not going to go away - you only have to > watch perl monks to see the frustration with last_insert_id, lob > reading, binding columns with types etc across DBDs to know this is > proving troublesome for the average user. Tim.
