<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'>But you are okay with 0 byte files as Paul proposed right? That wouldn’t change functionality. Just changing symlink to 0 byte. I don’t know about any other systems or how people package but packaging symlinks doesn’t work well on windows.<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'>For PostGIS 3.3.0 my package size doubled because we now have the spatial_ref_sys.sql files included in every micro.<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'>So I guess size is more important to me now as it is causing me to run out of disk space faster.<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><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 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>??????? ?????????????<br><b>Sent:</b> Monday, June 6, 2022 10:10 AM<br><b>To:</b> PostGIS Development Discussion <postgis-devel@lists.osgeo.org><br><b>Subject:</b> Re: [postgis-devel] PSC Vote: Get rid of micro in PostGIS Extension scripts (and comments from others)<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal>-1 from me.<o:p></o:p></p><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Forbidding to change SQL in micro is not a practice that we have now, unlike the version drop from a .so where the symlink practice was there for a while. <o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Extension files are not really a problem for end users now. It only looks awful when you look inside, not use. <o:p></o:p></p></div><div><p class=MsoNormal>It brings pain to developers (no way to change the SQL in micro) to ease the pain of computers (hundred files on FS).<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>The solution will be partial - the old files won't go away just because of it.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>If we're going to do something about it I believe it should be a thing bringing the version model closer to the Postgres intended one, where diffs are being generated or scripts are getting constructed in form of a DAG/chain of version migrations. This can also help fix the issue of extra features in newer PG for the same PostGIS, if we bake the PG version into the extension version - which differs really between PG versions.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Maybe what we need is a bit more indirection on the PG side - if we can have a table that lists all the upgrade scripts and the version pair will be a part of the table and filename can be arbitrary - then there won't be a problem of duplicated files on the filesystem. Maybe a way to register aliases as not to break the currently working way.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>A thing to look at: Postgres now has stored procedures that exist outside transactions, may happen that calling one will fix the problem with running postgis_extensions_upgrade() - we can do that twice internally.<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></div><div><p class=MsoNormal><o:p> </o:p></p></div></div><p class=MsoNormal><o:p> </o:p></p><div><div><p class=MsoNormal>пт, 3 июн. 2022 г. в 16:31, Regina Obe <<a href="mailto:lr@pcorp.us">lr@pcorp.us</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>Given this is not a trivial decision, I want to make sure no one has<br>reservations that can't be addressed.<br>That includes non-PSC.<br><br>+1 from me.<br><br>Detailed here (sorry I had the subject part wrong initially)<br><br><a href="https://trac.osgeo.org/postgis/ticket/5166" target="_blank">https://trac.osgeo.org/postgis/ticket/5166</a><br><br>This will be for PostGIS 3.3.0 onward (we'd still need to track all those<br>old files from previous versions, annoying)<br><br>Benefits:<br><br>1) Fewer extension files piling up moving forward<br>2) Not having this annoyance of remembering to add the latest micro (at<br>least for 3.3, will be useful for 3.4) moving forward.<br><br>Cons:<br>1) Doing micro SQL API changes will be harder, and so should be avoided. We<br>don't do that many of those anyway aside from security patches.<br>2) Nothing will happen if people do <br><br>ALTER EXTENSION postgis UPDATE; <br><br>If they are already on latest minor. We've had this issue all along by the<br>way (even for micros) for cases where people pg_upgrade from say 3.2.1 on<br>PG 11 to 3.2.1 on PG 14, because extension system doesn't recognize the idea<br>that a particular extension version might have extra features enabled for<br>newer versions of PostgreSQL.<br><br>However I think this can all be mitigated, for folks trained to use: <br><br>SELECT postgis_extensions_upgrade(); <br><br>strk -- I haven't checked, but I think you had changed this to work if the<br>PostgreSQL version script is different from the current PostgreSQL version.<br>If not we need to fix that anyway.<br><br>We could also add a force or an explicit PostGIS version arg to that which<br>we would need for development upgrades and when such a version is passed it<br>will force upgrade using next or ANY hack.<br><br>The force way should avoid touching system tables, since DBaaS won't allow<br>it, but I think doing a yoyo dance (next -> back to where we were) works<br>fine.<br><br><br><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></div></div></body></html>