[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