<br><br><div class="gmail_quote">On Wed, Aug 10, 2011 at 9:35 AM, Mark Cave-Ayland <span dir="ltr"><<a href="mailto:mark.cave-ayland@siriusit.co.uk">mark.cave-ayland@siriusit.co.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Perhaps I've not explained it very well, but the use of a key/value store is related into the slightly hacky way in which we use the PostgreSQL memory contexts to handle context pointers and free themselves as part of the memory cleanup process. It's not a specifically a key/value store that we are looking for.<br>
</blockquote><div><br>I think I'm not following. My understanding is that on the one hand (for projections), we want to lookup a ProjPJ object based on an integer srid. On the other hand (for prepped geoms/1d indices), we want to lookup a GEOSGeom object given a LWGEOM. Regardless of memory management issues, how does one avoid calling this a key/value store (or map or dictionary)? More importantly for the purpose of a generic API, how does one compare keys generically when they can sometimes be integers and sometimes LWGEOMs?<br>
<br>I withdraw the comment about depending on BerkeleyDB, as I've never used it and it appears problematic. However, I think the fact that a utility a basic as a generic key/value store cannot be easily located by google may speak to the difficulty in writing one for C. We may just be stuck maintaining one cache per key type...<br>
<br>Bryce<br></div></div>