<div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
> More to the point, I think, is that adding levels of indirection<br>
> increases the complexity of the whole thing, for relatively niche use<br>
> cases. We had a lot of debugging issues arise out of the backend<br>
> selection GUC, and I bet approximately nobody uses it. It would have<br>
> been far more effective to just have the 6 functions in question added a<br>
> ST_IntersectsCGAL() etc, etc, in terms of the real usage of PostGIS. The<br>
> backend switch was too smart by 1/2.<br>
> <br>
<br>
Probably. I don't remember exactly why we chose to use GUC. Functions in<br>
their own schema like sfcgal.ST_Intersects() could have been a solution<br>
as well (?)</blockquote><div><br></div><div>Can we change that for PostGIS 3.0, so that instead of postgis.backend=sfcgal one will set search_path=postgis_sfcgal,public?</div><div><br></div><div>This way postgis_sfcgal will be completely separate from postgis.so, and question on whether to demand presence of sfcgal during build will be much easier. </div></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>