<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><div><div><p class=MsoNormal style='margin-left:.5in'><o:p> </o:p></p></div><div><p class=MsoNormal style='margin-left:.5in'><span style='color:#1F497D'>> </span>It's not many steps, frankly. The "only" reason this is hard for casual users is because we almost always lack the "old postgis, new postgresql" or "old postgresql, new postgis" combination in packaging. We <span style='color:#1F497D'>> </span>could start begging packagers to cover those combos, if the pg_upgrade use case is a killer features (probably is)<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'><span style='color:#1F497D'>> </span>P<span style='color:#1F497D'><o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'>You underestimate the level of effort involved in doing that on both part of PostGIS to support old versions on newer versions, PostgreSQL packagers having to maintain multiple postgis versions on same PostgreSQL. <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'>What if a user wants to pg_upgrade from 9.4 to 10? Then what. They have to first upgrade to 9.5 then upgrade their postgis then upgrade to 9.6 then upgrade their postgis yadda yadda.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'>That happens all the 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'>You guys should just listen to Tom and do the right thing. I'm thru arguing with all of you. Do what you want.<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'>Thanks,<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'>Regina<o:p></o:p></span></p></div><div><p class=MsoNormal style='margin-left:.5in'><o:p> </o:p></p></div></div><div><p class=MsoNormal style='margin-left:.5in'><o:p> </o:p></p><div><p class=MsoNormal style='margin-left:.5in'>On Tue, Sep 5, 2017 at 1:13 AM, Sandro Santilli <<a href="mailto:strk@kbt.io" target="_blank">strk@kbt.io</a>> wrote:<o:p></o:p></p><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'>On Tue, Sep 05, 2017 at 09:17:36AM +0200, Sandro Santilli wrote:<br>> On Mon, Sep 04, 2017 at 10:12:00PM +0100, Mark Cave-Ayland wrote:<br>><br>> > The other particularly evil thought that occurred to me was do you need<br>> > to have a real PostGIS 2.3? What if you were to generate a compatibility<br>> > <a href="http://postgis-2.3.so" target="_blank">postgis-2.3.so</a> with empty stub methods - would that be enough to be able<br>> > to remove the extension post-upgrade and then install the new version?<br>><br>> The ALTER EXTENSION itself makes a single call to a function<br>> referencing the shared object and already handles an exception<br>> so it should work.<br>><br>> But generating a compatibility layer seems more work than just<br>> keeping the old signatures in the new code...<br><br>I've conducted an experiment to find out much of a dirty hack we'd<br>need to provide something working for pg_upgrade.<br><br>1) The tool explicitly tests for the referenced libraries to exist<br> and be loadable (touching a .so does not help, symlinking to<br> an arbitrary one does)<br><br>2) The tool ends up using pg_dump/pg_restore but does not have a<br> CREATE EXTENSION in the dump !<br><br><br>For comparison, this is what you find in the dump created by pg_dump:<br><br> CREATE EXTENSION IF NOT EXISTS postgis WITH SCHEMA public;<br><br>While this is what you find in the dump created by pg_upgrade:<br><br> -- For binary upgrade, create an empty extension and insert objects into it<br> DROP EXTENSION IF EXISTS "postgis";<br> SELECT pg_catalog.binary_upgrade_create_empty_extension('postgis', 'public', false, '2.4.0dev', '{16684}', '{"WHERE NOT (...<br><br>I'm not sure what's the benefit of pg_upgrade, but it's clearly threating<br>extensions in a different way from pg_dump. Specifically, in a way that<br>breaks the "EXTENSION will result in easier upgrades" dream...<br><br>To recap (this would be best added in the "upgrade" documentation of postgis):<br><br> - When upgrading from a PostgreSQL version to another, it's best to<br> follow the already documented "hard upgrade" procedure, as it takes<br> care of everything.<br><br> - If willing to use pg_upgrade (I dunno why would you want that) then<br> make sure to have the *exact_same* version of PostGIS available in<br> the target PostgreSQL version (will need a rebuild)<o:p></o:p></p><div><div><p class=MsoNormal style='margin-left:.5in'><br>--strk;<br><br><br>_______________________________________________<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" target="_blank">https://lists.osgeo.org/mailman/listinfo/postgis-devel</a><o:p></o:p></p></div></div></blockquote></div><p class=MsoNormal style='margin-left:.5in'><o:p> </o:p></p></div></div></body></html>