Hi. I still don't have enough time to fix things (sorry) but confirmed that the new collation_needed implementation doesn't leak any more. It may be worth a new dev release.
Thanks, Kenichi On Thu, 6 Aug 2009 16:34:53 +0200, "Dami Laurent (PJ)" <[email protected]> wrote: >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 _______________________________________________ DBD-SQLite mailing list [email protected] http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbd-sqlite
