Thanks, suggesting the paradigm of subclassing to deal with specific DBDs is helpful. I feel like that probably is the right way to deal with cross-DBD inconsistencies. I am already using this for some constructs in my code... For example, I have an abstract class called SQL::Conf that serves as a base for subclasses that parse the connection configurations for specific databases. There is a subclass of it called SQL::Conf::MySQL that parses .my.cnf files, and when you invoke the create_handle method of SQL::DBH it instantiates the appropriate SQL::Conf subclass based on the RDBMS that you specify either as an argument to the method, or as an environment variable. Right now, however, I'm not using such a paradigm for database schema detection... I guess I'm probably going to get burned when trying other databases. :-( Presently I have a SQL::Table class that takes just a handle and a table name, and issues a "describe table foo" query, and populates itself with the returned information. From what you've said, I suppose that that implementation will break when I try something other than MySQL. Ho-hum...