DBI Topic Areas

Type support

• Clarify specification: standardize mapping of SQL92 types to Ruby types

SQL Catalog, Schema and Object handling

• Should dbh.tables() and .columns() be modified to accept catalog and schema specifiers (ala perl-DBI?) [rf-1082, rf-3028]
• Same question for an eventual quote_identifier method

DBI naming consistency issues
CamelCasing vs. lower_with_underscores, handle['attribute'] vs. handle.accessor

• attribute access and naming style: dbh['AutoCommit'], but dbh.raise_error
• driver prefixes inconsistent: mysql_col_info['mysql_type'], but pg_col_info['array_of_type']
  pilcrow: should be @pg_ci[‘pg_array_of_type’]

Error handling

• Clarify specification of DBI::DatabaseError subfields [rf-26766, rf-27227]
• Improve consistency of DBDs’ .state and .err setting
• Re-assess DBI::DatabaseError subclasses
  pilcrow: ProgrammingError is highly suspect (IMHO), as it diagnoses the intent and competence of the coder. Some DDL, for instance DROPing a table, might be used by two db-aware processes to communicate (implied) state. After all, when I code systems apps, ENOENT isn’t necessarily bad nor unexpected

Taint handling

Most items fetched from SQL should be considered tainted, incl. dbh.database_name, which can be changed programmatically, by client library action, etc., and dbh.func(:some_server_parameter). Perhaps dbh['AutoTaint'] = true is passed down to DBI::Row so that individual elements are tainted upon fetch.

General features

• Named bind (in) parameter support [rf-3865]
• Multiple result set support [rf-23896, rf-24126]
  pilcrow: what would this look like?
• Statement preparation behavioral control [rf-21848, see also various perl DBDs]
  JDBC-like auto-preparation after “too many plain executions”? Explicit control? Per-DBD?
  pilcrow: should the DBI make an attempt at extracting the normalized SQL “action” (e.g., :select, :values, :insert, :update, :drop) and no. of params, for a DBD to determine if the statement can be profitably prepared at all?
• DBI::StatementHandle support for same-named columns
  pilcrow: pg happily returns same named columns. caveat coder, and discriminate fields by positional index if you run into this