On Sun, May 30, 2010 at 12:33:44PM +0200, H.Merijn Brand wrote: > 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.
[I'm not sure I understand the situation, but ...] it seems reasonable for the encoding of a table to be sticky, which implies some kind of cache in the $dbh. Tim.