Found a potential bug, but it looks deliberate, so I wanted to see why it
was coded that way. In SQL::Statement, open_tables is using
$self->tables() for mostly everything, which will contain the correct case
for all of the table names. (IE: FOOBAR = foobar and "FOOBAR" = FOOBAR)
However, when calling open_table (the DBD method), it uses the following
code:
undef $@;
eval {
my $open_name = $self->{org_table_names}->[$count];
$t->{$name} = $self->open_table( $data, $open_name,
$createMode, $lockMode );
};
So, it's deliberately grabbing the untouched (pre-corrected) table name
from org_table_names and passing it to open_table. What's the reasoning
behind this? Should we worry about it or not? If we correct it to enforce
proper ODBC case-sensitivity, that may suddenly break the DBD and users of
those DBDs that are expecting to query a CSV DB via "SELECT * FROM
UPPERCASE_filename" and getting an error because it's now going to convert
that to lowercase. If we don't correct it, there's the potential for two
different cased files to have the same table key and screwing stuff up with
JOIN. (Yeah, it's rare for somebody to actually be using both "FOOBAR" and
"foobar" in the same query...)
I guess this is delegating the enforcement of these standards to the DBD,
or should it be higher up?
--
Brendan Byrd/SineSwiper <sineswi...@gmail.com>
Computer tech, Perl wizard, and all-around Internet guru
