<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-size:10.0pt;}
@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'>I should add to this as strk and I both realized. We are screwing users when they move say from PostGIS 2.2 9.4 to PostGIS 2.2 9.5<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><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'>And that is currently not recoverable. Something we really need to fix. <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'>That's why we have on occasion like this poor fellow running PostGIS 2.2 with PostgreSQL 9.5 thinking he'd get the benefits of KNN and to his disappoint he did not.<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><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'>That’s the other reason I'd like to stop supporting versions of PostgreSQL that can't take full feature of a PostGIS version. It's so easy to mess them up.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'><a href="https://lists.osgeo.org/pipermail/postgis-users/2017-August/042287.html">https://lists.osgeo.org/pipermail/postgis-users/2017-August/042287.html</a><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><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'>I'd just assume minimize it by making it much easier for people to upgrade PostGIS and PostgreSQL at the same time.<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><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'>It would be much easier if we didn't try to support PostgreSQL versions that can't fully take advantage of a feature than upgrading to a newer PostgreSQL would go so much more smoothly<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'>Assuming we didn't continually change our lib name.<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><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><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'><o:p> </o:p></span></p><div><div style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal style='margin-left:.5in'><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>Paul Ramsey<br><b>Sent:</b> Tuesday, September 05, 2017 4:02 PM<br><b>To:</b> PostGIS Development Discussion <postgis-devel@lists.osgeo.org><br><b>Subject:</b> Re: [postgis-devel] PSC Vote: Change PostGIS library name to drop the minor<o:p></o:p></span></p></div></div><p class=MsoNormal style='margin-left:.5in'><o:p> </o:p></p><p class=MsoNormal style='margin-left:.5in'><o:p> </o:p></p><div><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><div><p class=MsoNormal style='margin-left:.5in'>On Sep 5, 2017, at 12:59 PM, Darafei Komяpa Praliaskouski <<a href="mailto:me@komzpa.net">me@komzpa.net</a>> wrote:<o:p></o:p></p></div><p class=MsoNormal style='margin-left:.5in'><o:p> </o:p></p><div><div><p class=MsoNormal style='margin-left:.5in'>Can PostGIS detect version mismatch (the NEED UPGRADE in full_version) and either perform a self-upgrade on first launch, or fail early with version mismatch message if it, say, doesn't have permissions?<o:p></o:p></p></div></div></blockquote><div><p class=MsoNormal style='margin-left:.5in'><o:p> </o:p></p></div><div><p class=MsoNormal style='margin-left:.5in'>Yes, it can figure out it has a mismatch (the so-called “script versions” checks you can see do that) but it does lack the power to do a self-upgrade in general. That requires a super-user.<o:p></o:p></p></div><div><p class=MsoNormal style='margin-left:.5in'><o:p> </o:p></p></div><div><p class=MsoNormal style='margin-left:.5in'>P<o:p></o:p></p></div><p class=MsoNormal style='margin-left:.5in'><br><br><o:p></o:p></p><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><div><p class=MsoNormal style='margin-left:.5in'><o:p> </o:p></p><div><div><p class=MsoNormal style='margin-left:.5in'>вт, 5 сент. 2017 г. в 22:53, Paul Ramsey <<a href="mailto:pramsey@cleverelephant.ca">pramsey@cleverelephant.ca</a>>:<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'><p class=MsoNormal style='margin-left:.5in'><br>> On Sep 5, 2017, at 10:58 AM, Mark Cave-Ayland <<a href="mailto:mark.cave-ayland@ilande.co.uk" target="_blank">mark.cave-ayland@ilande.co.uk</a>> wrote:<br>><br>> On 04/09/17 23:08, Regina Obe wrote:<br>><br>>> Creating a symlink from postgis-2.4 (compiled for PostgreSQL 10) and calling the link postgis-2.3<br>>> is a lot less evil I think.<br>>><br>>> In fact your PostGIS will still work after upgrade even if you don't rush to do<br>>><br>>> ALTER EXTENSION postgis UPDATE;<br>>><br>>> Because we did not remove any functions exposed via the SQL scripts. We only added functions.<br>>><br>>> You can even do this for postgis-2.2 and you'll be fine.<br>>><br>>> But as Darafei pointed out in the last comment<br>>><br>>><br>>> <a href="https://gist.github.com/Komzpa/994d5aaf340067ccec0e" target="_blank">https://gist.github.com/Komzpa/994d5aaf340067ccec0e</a><br>>><br>>> Many people just don't get that. It's a hard thing for people to fathom.<br>>><br>>> That you can take postigs-2.4 compiled for PostgreSQL 10 and call it postgis-2.3 PostgreSQL 10 and it will work.<br>>><br>>> BUT<br>>><br>>> postgis-2.3 compiled for PostgreSQL 9.6 CAN NOT BE USED by something looking for PostgreSQL 10 postgis-2.3<br>>> (though they both have 2.3 they are incompatible).<br>>><br>>> Thus my need to just ditch the minor to make every one's life easier.<br>><br>> Sure, I understand this. But reiterating my point from a previous email,<br>> pg_upgrade exists to update any on-disk binary changes and internal<br>> APIs. The assumption is that all other external libraries will remain<br>> the same, however I'm uncertain exactly what "the same" means in<br>> PostgreSQL terms.<br>><br>> For example if PostgreSQL 10 makes a binary change to the Datum struct<br>> or the AnalyzeStats struct compared to 9.6 then there is nothing we can<br>> do about this without a recompile, and I can't see how dropping the<br>> minor version would help here. So from what you are saying above, does<br>> that mean such a breaking change has taken place between 9.6 and 10?<br><br>There’s a core assumption that the versions of postgis and pgsql folks would be using would be kept functionally in sync through the mechanism of packaging: if you’re upgrading from<br><br>postgresql-9.5<br>postgresql-9.5-postgis-2.3<br><br>to<br><br>postgresql-9.6<br>postgresql-9.6-postgis-2.4<br><br>then you can do a process of<br><br>- install new packages (now your install it dead until you)<br>- pg_upgrade<br>- start up your new instance<br>- finally ALTER EXTENSION postgis UPDATE …<br><br>in some respects this is also a “magic” upgrade since if you forget the finally step your system will still probably work since 99.9% of the old functions will still bind to the new postgis.so.<br><br>It seems like a “least worst” option given the current state of affairs, though I’d rather do it for 3.x than a 2.x. YMMV kind of a thing.<br><br>It would be nice if the pgsql extension mechanism had a hook where it could ask the extension what it thinks its version is, so that pgsql itself could raise the issue “hey, your extension thinks it’s version 3.0, but your library is version 3.1, want to fix that?”.<br><br>Because the final black box at the end of all this stuff is the fact that the “ALTER EXTENSION UPDATE” step seems like extra voodoo: "why do I have to do this, I already installed the update via yum/apt-get, right?"<br><br>ATB,<br>P<br><br><br>><br>><br>> ATB,<br>><br>> Mark.<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" target="_blank">https://lists.osgeo.org/mailman/listinfo/postgis-devel</a><br><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" target="_blank">https://lists.osgeo.org/mailman/listinfo/postgis-devel</a><o:p></o:p></p></blockquote></div><p class=MsoNormal style='margin-left:.5in'>_______________________________________________<br>postgis-devel mailing list<br><a href="mailto:postgis-devel@lists.osgeo.org">postgis-devel@lists.osgeo.org</a><br><a href="https://lists.osgeo.org/mailman/listinfo/postgis-devel">https://lists.osgeo.org/mailman/listinfo/postgis-devel</a><o:p></o:p></p></div></blockquote></div><p class=MsoNormal style='margin-left:.5in'><o:p> </o:p></p></div></body></html>