<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=utf-8"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:12.0pt;
        font-family:"Times New Roman",serif;}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:purple;
        text-decoration:underline;}
span.EmailStyle17
        {mso-style-type:personal-reply;
        font-family:"Calibri",sans-serif;
        color:#1F497D;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-family:"Calibri",sans-serif;}
@page WordSection1
        {size:8.5in 11.0in;
        margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
        {page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-US link=blue vlink=purple><div class=WordSection1><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'><o:p> </o:p></span></p><div style='border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt'><div><div style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>From:</span></b><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'> postgis-devel [mailto:postgis-devel-bounces@lists.osgeo.org] <b>On Behalf Of </b>Darafei "Kom?pa" Praliaskouski<br><b>Sent:</b> Sunday, November 25, 2018 4:13 AM<br><b>To:</b> PostGIS Development Discussion <postgis-devel@lists.osgeo.org><br><b>Subject:</b> Re: [postgis-devel] Making SFCGAL mandatory<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal style='margin-bottom:12.0pt'><o:p> </o:p></p><div><div><p class=MsoNormal>On Thu, Nov 22, 2018 at 10:57 PM Regina Obe <<a href="mailto:lr@pcorp.us">lr@pcorp.us</a>> wrote:<o:p></o:p></p></div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in'><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'>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.</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'>It's the fact it's part of postgis library and not a separate library like rtpostgis or postgis_topology that bugs me.</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'>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.</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'>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.</span><o:p></o:p></p></div></div></blockquote><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>1. we remove branching on postgis/sfcgal for same functions. They always go to postgis.<br>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.<br>3. functions like ST_StraightSkeleton skeleton straight to postgis_sfcgal.so.<br>4. postgis.so has no linkage to sfcgal.<br>5. postgis_sfcgal.so may have linkage to whatever it needs.<br>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.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Does it look like a plan?<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal> <o:p></o:p></p><p class=MsoNormal><b><i><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'>[Regina Obe] <o:p></o:p></span></i></b></p><p class=MsoNormal><b><i><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'>Sorry was reading out of order so confused you and Paul.  As mentioned before, okay with me as long as we don't need to rename functions that are only available via SFCGAL.<o:p></o:p></span></i></b></p><p class=MsoNormal><b><i><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'>Renaming ST_3DIntersects, ST_Intersects, ST_Union (I'm not sure if SFCGAL adds anything of value for the 2D case, so maybe we just don't bother with the 2D overloads) Hey that will fix my ST_ConcaveHull which I had to change to ST_UnaryUnion to avoid SFCGAL ST_Union.<o:p></o:p></span></i></b></p><p class=MsoNormal><b><i><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'><o:p> </o:p></span></i></b></p><p class=MsoNormal><b><i><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'>That said – only thing I'm wondering about is we've never tried to remove a GUCs before.  Is there any consequence we need to worry about or it wouldn't matter because as you discovered you can make up any postgs.whatever variables without having a GUC behind it.</span></i></b><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'><o:p></o:p></span></p></div></div></div></div></div></body></html>