Sure, I understand that DBD::ODBC is a DBD driver meant to be used with DBI. That is precisely what I thought was the problem.
ODBC is a layer, is it not (I am really not an expert there), that gives you a standard way to access different kinds of database. DBI is a layer that gives you a standard way to access different kinds of database. I am sure one could generate enough material for ten threads just talking about their differences, but this is the conceptual overlap that I was talking about.
By using DBD::ODBC as your go-to guy, aren't you condemning yourself to using two abstraction layers most of the time? PostgreSQL (or another database) at the bottom, ODBC on top of that, DBI on top of that and your logic on top. Town Musicians of Bremen, where the Dog and the Cat do similar gigs. What would we lose by putting the Dog out to pasture?
There may well be problems (certain combinations of Perl, DB etc.) that are best (or only) solved by having the Dog in there, but I thought that wouldn't make the best default solution.
I see your point and it is valid. Actually, if it were up to me, I'd say beef up ODBC to make it more robust, more able to handle complex data types, aggregates, different call conventions, more detailed error reporting, no-configuration connections, etc., and make that the only database interface. That way we'd separate out two distinct parts:
how to connect to databases generally from a given programming environment
how to connect to a given database type
I mean, either that or replace ODBC with something better that accomplishes a similar goal.
Frankly I consider the current system, where each database needs a separate driver for each programming environment, kind of pointless.