[postgis-devel] Making SFCGAL mandatory

Regina Obe lr at pcorp.us
Sat Nov 17 00:23:45 PST 2018


>  How about we just overload ST_Intesects, ST_3DIntersects and so forth.  We love overloading ☺
>  And then get rid of the backend.

>  So anyone who wants to use the cgal version would do

> ST_Intersects(geom1,geom2, 'cgal')

Disregard my proposed solution here of overloading the functions.  I just realized that wouldn't solve the ultimate gripe I had of SFCGAL being part of the postgis lib.
It would only give more granular control of when to use SFCGAL/PostGIS overlapping functions than Backend GUC does.

The only palpable solution would seem to be Paul's and even that seems like too breaking to warrant gaining ability to break the Siamese twins.
 I'd feel if we go down the rename path, to be consistent, we'd want to do that with all SFCGAL functions which would be too breaking for the minor benefit.
The only minor benefit I would see from renaming the functions is it would be clearer which ones require SFCGAL, but having to type in the extra words CGAL seems hardly worth it.

The only other annoying things about the GUC backend is:

1) the message every once in a while about backend already loaded
2) The danger you might forget to upgrade the SFCGAL extension when you upgrade PostGIS


Both issues are largely resolved by not changing the .so name of the library (so should be good for another 8-10 years) because
any functions we take out of sfcgal would be stubbed with an error so people know they need to upgrade
and since most sfcgal functions have minimal SQL, I don't see their function API definition changing that much except to add new ones.

Maybe we should just keep the backend as it is as the other options leave a bad taste in my mouth.

Thanks,
Regina



More information about the postgis-devel mailing list