[DBD-SQLite] collation_needed() : new implementation

Kenichi Ishigaki kishigaki at gmail.com
Mon Aug 10 16:19:04 GMT 2009


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)" <laurent.dami at justice.ge.ch> 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
>DBD-SQLite at lists.scsys.co.uk
>http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbd-sqlite





More information about the DBD-SQLite mailing list