[postgis-devel] Making SFCGAL mandatory

[Regina Obe]

From: postgis-devel [mailto:postgis-devel-bounces at lists.osgeo.org] On Behalf Of Darafei "Kom?pa" Praliaskouski
Sent: Sunday, November 25, 2018 4:13 AM
To: PostGIS Development Discussion <postgis-devel at lists.osgeo.org>
Subject: Re: [postgis-devel] Making SFCGAL mandatory

 

 

On Thu, Nov 22, 2018 at 10:57 PM Regina Obe <lr at pcorp.us <mailto:lr at pcorp.us> > wrote:

Not following how that helps getting rid of SFCGAL from the postgis library itself.  The GUC thing doesn't bother me that much and will annoy me even less when 3.0 comes out since we will not have two backends coexisting during upgrade for the life of PostGIS 3 major.

 

It's the fact it's part of postgis library and not a separate library like rtpostgis or postgis_topology that bugs me.

 

Because for packaging you can never cleanly with one compile a separate package for postgis_sfcgal that depends on postgis  and a package for just postgis.

Your postgis package will always be infected with postgis_sfcgal if it were ever to be used as a dependency in the postgis_sfcgal package.

 

1. we remove branching on postgis/sfcgal for same functions. They always go to postgis.
2. if SFCGAL func version adds some value or behavior change, we untangle them by names (not just adding _SFCGAL, but semantic difference) and put sfcgal version into postgis_sfcgal extension.
3. functions like ST_StraightSkeleton skeleton straight to postgis_sfcgal.so.
4. postgis.so has no linkage to sfcgal.
5. postgis_sfcgal.so may have linkage to whatever it needs.
6. if there is a difference in implementation (postgis knows no TIN, sfcgal knows no curve) that goes to each of untangled function's manual entry.

 

Does it look like a plan?

 

 

[Regina Obe] 

Sorry was reading out of order so confused you and Paul.  As mentioned before, okay with me as long as we don't need to rename functions that are only available via SFCGAL.

Renaming ST_3DIntersects, ST_Intersects, ST_Union (I'm not sure if SFCGAL adds anything of value for the 2D case, so maybe we just don't bother with the 2D overloads) Hey that will fix my ST_ConcaveHull which I had to change to ST_UnaryUnion to avoid SFCGAL ST_Union.

 

That said – only thing I'm wondering about is we've never tried to remove a GUCs before.  Is there any consequence we need to worry about or it wouldn't matter because as you discovered you can make up any postgs.whatever variables without having a GUC behind it.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20181127/5cbe743a/attachment.html>