[postgis-devel] liblwgeom.so

[Paragon Corporation]

> I know the "we know it works" argument very well, but you 
> have to draw a line between stability and innovation. Given 
> we're going 2.0 (how many things known to work we left 
> already?) it seems a good occasion to move forward to me.

I'm on Paul's side on this one.  I personally would really like to get
PostGIS 2.0 out before
the new year.  I'm already pissed that it looks like we are going to miss
the 9.1 release cycle.

Innovation for innovation sake is folly.  We'll have plenty of occasion for
this like when we
try to introduce pgrouting in 2.1 or 2.2. This stuff doesn't require on-disk
format change so there isn't any reason why it can't wait
till 2.1 or 2.2 when tere would be more of a need for it.

BTW - I redownloaded everything from scratch and my build is still building
only static libraries.
So this dynamic thing isn't happening for me anyway.

 
> About mixing static linking and dynamic linking, I left the 
> postgresql module statically linked to avoid the complexity 
> of pre-installation testing which would require (for a 
> dynamically linked module) a way to have the already running 
> PostgreSQL instance find a yet-to-be-installed library. I'm 
> not sure that's possible at all. In order to fix that we 
> should rework the tester to at least fire a completely new 
> instance of postgres (which could actually also fix other 
> inconsistencies, like the need to be superuser there).

Yuck.  As far as static vs. dynamic.  All else being equal, I prefer
static unless it reduces a user's freedom to replace a newer version (e.g.
GEOS or proj or whatever).

Here there is absolutely no gain since you would never mismatch the versions
and dynamic makes it possible
to accidentally do so.

As far as Mark's comment on saves memory.  the only place I would need
saving memory is in PostgreSQL
and if we can't dynamically link for postgis then there is absolutely no
gain whatsoever.  I don't know about others
but it's not too often that I run shp2pgsql, pgsql2shp and when I do it's
often not on the PostgreSQL server where a 
shared library would even help which hmm it doesn't because we can't make
postgis dynamic.
 
> About taking responsibility for the libpgcommon issue I agree 
> it is on me. I'm just back from holiday and will be on it. 
> Mark: I asked for your opinion because I belive it has to do 
> with using or not PGXS, but I could be wrong. Eventually I'd 
> drop libpgcommon and simply link its object files into the 
> respective libraries. It's been a mistake on my side to 
> commit the libpgcommon thing while working on liblwgeom, 
> raising the warning levels. Sorry for that.
> 
I think you may be right about the PGXS thing.  I think Mark said 
8.4 was the last version to use the hack he put in place so that might be
why I can compile
9.0 and 9.1 fine and only have issue with 8.4.  could have something to do
with that hack. 
I apologize myself I haven't really bothered trying to debug the issue
myself.  
Just been complaining and over-acting the damsel in distress role :)

Thanks,
Regina