<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">сб, 17 нояб. 2018 г. в 11:23, Regina Obe <<a href="mailto:lr@pcorp.us">lr@pcorp.us</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">>  How about we just overload ST_Intesects, ST_3DIntersects and so forth.  We love overloading ☺<br>>  And then get rid of the backend.<br><br>>  So anyone who wants to use the cgal version would do<br><br>> ST_Intersects(geom1,geom2, 'cgal')<br><br>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.<br>It would only give more granular control of when to use SFCGAL/PostGIS overlapping functions than Backend GUC does.<br></blockquote><div><br></div><div>What if we treat it all just like GEOS version test?</div><div>i.e. there is always a function from SFCGAL, and if PostGIS is compiled without it it just says "please recompile", and if there is we're lucky and it just works. <br><br>Regarding solid and non-solid intersection - what if they are indeed two distinct operations, just like ST_Contains and ST_Intersects that mean basically the same thing for point-and-polygon, but start differing with higher dimensions? Maybe we can find two different words for solid intersection and non-solid intersection operations, and then one of them will be GEOS and another CGAL?</div><br class="inbox-inbox-Apple-interchange-newline"></div></div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">Darafei Praliaskouski<br>Support me: <a href="http://patreon.com/komzpa">http://patreon.com/komzpa</a></div></div>