<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7654.12">
<TITLE>collation_needed() : new implementation</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/rtf format -->
<P><FONT SIZE=2 FACE="Arial">Hi folks,</FONT>
</P>
<P><FONT SIZE=2 FACE="Arial">For info, I just committed a new implementation for "collation_needed", that no longer uses dynamic memory allocation, and therefore should no longer leak. The extra information needed is just an additional field in the imp_dbh_st struct (this makes sense because at any point in time, a dbh cannot have more than one "collation_needed" handler -- I should have realized that in the first place!).</FONT></P>
<P><FONT SIZE=2 FACE="Arial">To address Adam's argument about global registry, I first thought of a bunch of methods "register_global_collation", "list_global_collations", etc., that would hide the internal hash implementation. But the API became heavy, and finally it seemed more perlish to expose that stuff as a regular hash, so that clients can use all Perl idioms for hashes --- except that this is a "write-once" hash : any attempt to modify or delete an existing entry raises an exception. Hackers who for any obscure reason would need to override an existing entry can always use the 'tied' API -- but then there is really no risk of doing it accidentally.</FONT></P>
<P><FONT SIZE=2 FACE="Arial">The doc has been adapted in consequence.</FONT>
</P>
<P><FONT SIZE=2 FACE="Arial">I hope these solutions are satisfactory to everyone.</FONT>
</P>
<P><FONT SIZE=2 FACE="Arial">Greetings, Laurent Dami</FONT>
</P>
</BODY>
</HTML>