> > That's what DBI wrappers do, and I have one of those too. But my DBI > > wrapper reads its connection information for each "logical" data source from > > a hash. Then there's a build_dsn() method that assembles the pieces > > according to the name of the driver. > > > > If each DBD did that for me, I could just pass a reference to my connection > > info hash directly to DBI->connect() and then remove the build_dsn() code > > from my wrapper. > > Assuming that each DBD used the same names for elements with the same meaning > (database vs dbname vs db vs sid etc etc). > > Tim.
mandating a new method for all compliand DBDs is, as ever, outrageeous. Here's a proposed compromise: A new DBD that takes the elements of the attributes hash, and at connect time this DBD will build the DSN (or croak and complain explicitly about what is missing in a well defined way) and return a real $dbh resulting from calling DBI->connect with the build DSN. DBI doc tells us: $dbh = DBI->connect($dsn, $user, $password, { RaiseError => 1, AutoCommit => 0 }); DBD::dsn (DBD::any? DBD::DBH?) would work like this: $dbh = DBI->connect('DBI:DBH', $user, $password, { RaiseError => 1, AutoCommit => 0, host => $dbhost, dbd => 'pg', port => $dbport }); That way, DBI->connect doesn't need to be rewritten to allow a hash -- it already allows the %attr hash -- and the intermediate DSN created by the build_dsn method is hidden away in the inner workings. Am I missing something?