In DBI-1.611 I introduced f_encoding for tables. That works great.
In 1.611, f_encoding was evaluated from the database handle each time a
table (file) was opened, so
my $dbh = DBI->connect ("dbi:File:");
$dbh->{f_encoding} = undef; # raw mode
my $sta = $dbh->prepare ("select * from foo");
$dbh->{f_encoding} = "utf-8"; # Unicode UTF-8
my $stb = $dbh->prepare ("select * from foo");
works as this coder would expect: $sta opened table foo in raw mode,
whereas $stb open THE SAME table in utf-8 encoding.
Now with the rework for DBD::File, the meta-info for a table is stored
only once, on first opening of the table. This is to ensure being able
to follow ANSI SQL in case preserving/ignoring issues, which IMHO is a
good thing.
On the one hand, the code in 1.611 could be considered more DWIM than
the current state, but on the other, something could be said for the
new situation too: it is insane to have two concurrent handles on the
same file in two different encodings.
OTOH, it is imaginable that when I CLOSE a handle to a table and open
it again, now in different encoding, that action is completely legit.
That would mean we'd have to change a few innards to enable resetting
some previous gained knowledge about tables OR flag a table being
closed, and re-evaluate flags like f_encoding when the table is opened
again.
--
H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/
using 5.00307 through 5.12 and porting perl5.13.x on HP-UX 10.20, 11.00,
11.11, 11.23, and 11.31, OpenSuSE 10.3, 11.0, and 11.1, AIX 5.2 and 5.3.
http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/
http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
