[postgis-devel] Making SFCGAL mandatory

Paul Ramsey pramsey at cleverelephant.ca
Sun Nov 25 12:36:50 PST 2018


On Sun, Nov 25, 2018 at 1:12 AM Darafei "Komяpa" Praliaskouski <
me at komzpa.net> wrote:

>
>
> On Thu, Nov 22, 2018 at 10:57 PM Regina Obe <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?
>
>
To me it looks like a plan. No more swappable back-end, distinct function
names for cases where functionality overlaps but we want to retain access
to both. Much simpler access to SFCGAL, and the ability to build a cleanly
separable postgis_sfcgal, works for me.

P.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20181125/2a9add0b/attachment.html>


More information about the postgis-devel mailing list