Tim Bunce wrote:
>
> Umm, carrying on from there... move %get_info_constants into DBD::Oracle::GetInfo
> and make get_info do:
So is this the way to do get_info() for DBD::CSV and DBD::AnyData? The
situation for those is a bit more complex since the return values depend
not only on the driver version in use, but also on the SQL::Statement
version in use.
sub get_info {
my($dbh, $info_type) = @_;
my $v;
if ($SQL::Statement::VERSION > 1) {
require DBD::SQL_Statement::GetInfo;
$v = $DBD::SQL_Statement::GetInfo::info{int($info_type)};
}
else {
require DBD::SQL_Statement_XS::GetInfo;
$v = $DBD::SQL_Statement_XS::GetInfo::info{int($info_type)};
}
$v = &$v($dbh, $info_type) if ref $v eq 'CODE';
return $v;
}
The situation for DBD::Excel will be even more complex since it will
depend on the DBD in use, the SQL::Statement in use, and on the version
of Excel in use. If one wanted to get even more complex, one would need
to determine the versions of sub-modules also (e.g.
Spreadsheet::ParseExcel in the Excel case or XML::Twig/XML::Parser when
AnyData is handling XML). To know how detailed to get, we'd have to
know the kinds of things get_info() will ultimately be used for. In
other words, what constants will be required by DBI and how will they be
used? I know that I will be using the ones related to SQL syntax for my
own purposes in SQL::Statement, but which of the others will actually be
used by DBI to change DBI behaviour?
Also: shouldn't we be wrapping the requires in evals?
--
Jeff
