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.


On Thu, 6 Aug 2009 16:34:53 +0200, "Dami Laurent (PJ)" 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

The doc has been adapted in consequence.

I hope these solutions are satisfactory to everyone.

Greetings, Laurent Dami
DBD-SQLite mailing list

Search Discussions

Discussion Posts


Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 2 of 2 | next ›
Discussion Overview
groupdbd-sqlite @
postedAug 6, '09 at 2:34p
activeAug 10, '09 at 4:19p



site design / logo © 2021 Grokbase