Hi folks, 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!).
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. The doc has been adapted in consequence. I hope these solutions are satisfactory to everyone. Greetings, Laurent Dami
_______________________________________________ DBD-SQLite mailing list [email protected] http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbd-sqlite
