Hi, Tom,
sorry for replying so late, but my time for Perl development
gets fewer and fewer.
> I've included a patch to fix the a problem using table_info
> and DBD::Proxy. Currently the DBD::Proxy attempts to execute a
> statement called "SHOW TABLES".
Sorry, but that's not the case. The table_info method of
DBD::Proxy does indeed execute a table_info method on the server
side:
my($numFields, $names, $types, @rows) = eval { $rdbh->table_info(@_) };
However, it continues:
my $sth = DBI::_new_sth($dbh, {
'Statement' => "SHOW TABLES",
'proxy_params' => [],
'proxy_data' => \@rows,
'proxy_attr_cache' => { 'NAME' => $names, 'TYPE' => $types }
});
$sth->SUPER::STORE('NUM_OF_FIELDS' => $numFields);
return $sth;
The "SHOW TABLES" thing is just, because the DBI specs require to
return a statement handle, which in turn requires a "Statement"
attribute. We could choose whatever else for "SHOW TABLES", it's
merely a placeholder.
Reading through your patch, I honestly don't like it. I see no sense
in caching the table_info method. First of all, it is typically used
in interactive applications, where another 0.5 seconds don't hurt.
Second, it does not consider that the cache becomes invalid with
any CREATE TABLE or DROP TABLE statement. I am not the DBI main-
tainer, but I'd vote against, if Tim cares.
I think, you should better describe what the actual problem is?
Sorry,
Jochen
