RE: Placeholders: since DBIv1 already supports both forms of PH's, I see no reason to deprecate or abandon either form. Furthermore, to my knowledge, none of (ODBC, JDBC, ADO.NET) has abandonded or deprecated the ? form, so I don't see the need for DBI to.
RE: LOBs and "SQL Parse Trees": having recently implemented LOB support for a JDBC driver (and soon for a DBD), I can assure you that SQL parse trees are unneeded to support them. For databases robust enough to support LOBs, they'll almost always provide sufficient metadata info and/or SQL syntax to manipulate them; only databases which don't support LOBs have that difficulty. Furthermore, a quick review of the current DBI will indicate that Mssr. Bunce has already implemented some stub methods for generalized support. RE: SQL Parse Trees (or other non-SQL query input) Since none of (ODBC, JDBC, ADO.NET) seems compelled to impose this concept on driver writers, I don't see why DBI should be the vanguard. However, implementing a subclass of DBI to support it seems technically feasible, so I'd suggest that those of you championing this requirement implement one on DBI v1. Feel free to use DBIx::Chart to bootstrap your project. As the proponents of this notion are so generous with their requirements for those of us who develop DBI drivers and/or contribute development efforts to the DBI itself, I'm sure they won't object if I provide a few requirements: 1. For DBI drivers which support them, your subclass must support - arbitrary numbers and levels of JOINs (including various outer, and non-equijoins) - arbitrarily nested subqueries (including correlated) - HAVING and GROUP BY clauses - ORDER and LIMIT clauses - updatable cursors - database-specific SQL extensions 2. It must function with current versions of 40% of DBD's created or updated on CPAN since Jan. 1, 2003. Said 40% must include - DBD::ODBC - DBD::Oracle - DBD::Pg - DBD::MySQL - DBD::CSV - one 'exotic' driver (e.g., DBD::iPod or DBD::Amazon, but excluding DBD::Google, whose syntax is too simplistic for a meaningful test) (FWIW: Past experience (e.g., execute_array()) leads me to believe Mssr. Bunce's requirements are likely much higher than 40%, so "choose wisely, grasshopper") BTW: If you need a list of DBD's meeting said requirement, let me know, I just pulled one down. 3. It cannot require any changes to either DBI or the selected DBD's. 4. It must produce a database-independent conforming set of error codes (feel free to use SQLSTATE aka $h->state) 5. It must be uploaded to CPAN, and list, and demonstrably function against, the DBD's selected in requirement (2) above. Once you've implemented the subclass, you'll have empirical proof of the feasibility, and, more importantly, you'll be able to port the subclass to DBIv2, without any additional burden on DBI developers. Regards, Dean Arnold Presicient Corp.