[postgis-devel] Common Code

[Chris Hodgson]

Isn't all this "caching" for storing one or maybe two objects ( proj 
contexts, geos geometries, etc) for the length of a single query? I 
think any kind of database, in-memory or not, is way overkill. This 
doesn't even require a hash table... just a short list of the most 
recently used objects.

If there is any place for an embedded DB it is in proj itself, instead 
of reading through the entire EPSG file, so that it could have some kind 
of index, but that discussion is for another list.

I agree with Mark that if we can come up with a simple design for 
abstracting the caching API separately from postgres, that it would be 
nice to be able to test it outside of postgres. And it could possibly be 
of use to whomever else might be using lwgeom, if in fact alternate DBs 
are the primary target user for liblwgeom. Also, understanding that this 
is the case, I retract my earlier statement about not seeing the need 
for decoupling postgis versions from liblwgeom. I agree with strk's 
step-wise approach to moving in this direction.

Cheers,
Chris


aperi2007 wrote:
>
> >What about using BerkeleyDB in a RAM only configuration as a key/value
> >store? It's mature, stable, and multiplatform.
>
> Should be sqlite a valid alternative to BerkeleyDB ?
> It also allow a memory-only DB.
>
> Regards,
>
> Andrea
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel