[postgis-devel] liblwgeom symbols exported by postgis module

[Paragon Corporation]

>> If we make changes to liblwgeom in a minor release, even if the api did
not change, I don't want my older PostGIS  affected by it.

> A use case I understand, but one that seems developer specific. A user
rarely needs that kind of reproducibility. Why on earth would he *not* want
a fix in liblwgeom to affect older PostGIS versions?
Because the fix may not be a simple bug fix, but a performance enhancement.
I think we had a couple of those in PostGIS 2.2 (luckily the lib name is not
the same between 2.1 and 2.2 but will be more of an issue now that we
separated the .so naming
>From PostGIS)

To me liblwgeom and PostGIS are pretty synonymous, and I think Paul feels
the same way which is why we come out being very antagonistic.  We just
switched in PostGIS 2.2. to have liblwgeom not versioned with same version
number as PostGIS, and I'm beginning to regret this decision.

So yes my need to be able to run PostGIS 2.1 and PostGIS 2.2 on the same
Postgres instance, IS a developer need.  If I can't do that without jumping
thru hoops, then many PostGIS users are screwed
Because it means we less sure we didn't break things.

The other issue is since liblwgeom doesn't rely on PostgreSQL.  It's
possible for someone to be running two instances of PostgreSQL (a 9.3) and a
9.4 for example.

They upgrade their 9.3 pulling a PostGIS 2.1.8 (which happens to have a
liblwgeom)  
Then later they install 9.5 -- install PostGIS 2.2.0 (well luckily they have
different liblwgeom, but let's assume they didn't)

Then later they upgrade their PostGIS 2.1.8 to PostGIS 2.1.9  (the liblwgeom
is newer than the PostGIS 2.2.0), is it okay 2.2.0 is using this 2.1.9 one.
I cringe at the thought.


>> Because I use that for easier regression testing knowing that the only
thing that changed is PostGIS is PostGIS (e.g. I'm fine they share the same
geos etc. cause I'm not testing that and like all else being equal).

> This basically means you're not considering liblwgeom an external library.
That's fine as well, but then it should probably not be one.

Yes exactly -- that's what Paul and I have been saying all along.  Fork it
if you want to use it for your own needs but don't screw with PostGIS we
don't want that extra headache and we aren't seeing any rewards :)



> Again: By shipping liblwgeom as a library, you're making your code more
accessible and more useful. But you're also taking the burden of API
decisions, stability and separation. Like having to specify which versions
of liblwgeom work with what versions of 
> PostGIS (and test those combinations, as with all other libraries).

> To me it still seems like the PostGIS project is undecided there and wants
all the benefits, but none of the associated costs. That's understandable as
well, but wishful thinking.

I'm not sure what benefits you are talking about.  I see only costs, not
benefits.  Strk may see benefits.  I don't.  My packaging job has gotten a
tinsy harder which I can live with if Sandro gains something from it.

The reason we broke it internally is as Mark mentioned so we could easily
test the algorithms separately from PostgreSQL.  That is the only benefit I
see and ever wanted.


Again sorry guys.  I didn't eman to come out being so antagonistic about
this whole thing, I just don't think we enough bandwidth for the inherited
costs of this break.

Thanks,
Regina