<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Thu, Nov 15, 2018 at 8:20 AM Regina Obe <<a href="mailto:lr@pcorp.us">lr@pcorp.us</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
> -----Original Message-----<br>
> From: postgis-devel [mailto:<a href="mailto:postgis-devel-bounces@lists.osgeo.org" target="_blank">postgis-devel-bounces@lists.osgeo.org</a>] On Behalf<br>
> Of Sandro Santilli<br>
> Sent: Thursday, November 15, 2018 5:25 AM<br>
> To: PostGIS Development Discussion <<a href="mailto:postgis-devel@lists.osgeo.org" target="_blank">postgis-devel@lists.osgeo.org</a>><br>
> Subject: Re: [postgis-devel] Making SFCGAL mandatory<br>
> <br>
> On Thu, Nov 15, 2018 at 01:08:54PM +0300, Darafei "Kom?pa" Praliaskouski<br>
> wrote:<br>
> <br>
> > ><br>
> > > Probably. I don't remember exactly why we chose to use GUC.<br>
> > > Functions in their own schema like sfcgal.ST_Intersects() could have<br>
> > > been a solution as well (?)<br>
> ><br>
> > Can we change that for PostGIS 3.0, so that instead of<br>
> > postgis.backend=sfcgal one will set search_path=postgis_sfcgal,public?<br>
> <br>
> +1<br>
> <br>
> --strk;<br>
> _______________________________________________<br>
> postgis-devel mailing list<br>
> <a href="mailto:postgis-devel@lists.osgeo.org" target="_blank">postgis-devel@lists.osgeo.org</a><br>
> <a href="https://lists.osgeo.org/mailman/listinfo/postgis-devel" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/postgis-devel</a><br>
[Regina Obe] <br>
What?  NO  -1<br>
<br>
That is a super breaking change.  We'd have to remove the postgis schema qualfications in SFCGAL since we wouldn't know where postgis is installed.  We've already got issues with postgis.topology and postgis_tiger_geocoder because of this.<br>
Let's not compound the issue.<br></blockquote><div><br></div><div>Agreed. </div><div><br></div><div>Yes, this would have be an interesting approach back when we had the option, but sort of assumes using specific install schemas as a general policy, which not everyone does.</div><div>Since I was complaining about it being a basically unused features, I was this morning wondering about removing the run-time backend switch?  If we want to keep binding to specific CGAL functions that overlap GEOS functionality, then just naming them appropriately (CGAL_Intersects()? ST_IntersectsCGAL()?) would hardly be the end of the world.</div><div><br></div><div>P.</div><div><br></div></div></div>