[postgis-devel] what's the main job of lwgeom_api.c

Mark Cave-Ayland mark.cave-ayland at siriusit.co.uk
Mon Jun 23 09:34:54 PDT 2008


Mark Cave-Ayland wrote:

> Not really. I have a very rough idea of what is in those files, but I've 
> never looked deeper than fixing bugs. If we can build these files into a 
> separate library, perhaps then it would be a good time to consider 
> tidying them up.

After about half a day of fiddling, I now have a test build that splits 
the low level geometry routines into a separate static library called 
liblwgeom.a which is then linked into the resulting PostgreSQL extension 
library. That's the good news.

The bad news is that in order to configure PostGIS to use liblwgeom, we 
need a way of initialising the memory allocation functions as is 
currently done in liblwgeom.c. And PostgreSQL doesn't support 
initialisation functions in shared libraries until 8.2 :(

I have thought of a way to make this work on older versions by hooking 
the default allocation functions so that the first time they run, they 
attempt to call an initialisation function with a fixed name such as 
"lwalloc_init". Libraries linked to liblwgeom can then make use of 
functions with these fixed names to set the correct allocations routine 
for subsequent calls, and then everything works as intended.

So the question is: should we implement a messy workaround, or bump the 
minimum version for SVN trunk to 8.2 so we can use the in-built 
PostgreSQL functions (and possibly risk alienating people in the 
process)? Another thing to think about is that if we do the latter, will 
this exclude potential use within other systems that don't provide 
shared library initialisation functions? I'm currently leaning towards 
the former, but I'd appreciate input from everyone else...


ATB,

Mark.

-- 
Mark Cave-Ayland
Sirius Corporation - The Open Source Experts
http://www.siriusit.co.uk
T: +44 870 608 0063



More information about the postgis-devel mailing list