<div dir="ltr">-1 from me.<div><br></div><div>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. </div><div><br></div><div>Extension files are not really a problem for end users now. It only looks awful when you look inside, not use. </div><div>It brings pain to developers (no way to change the SQL in micro) to ease the pain of computers (hundred files on FS).</div><div><br></div><div>The solution will be partial - the old files won't go away just because of it.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div><br></div><div><br style=""></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">пт, 3 июн. 2022 г. в 16:31, Regina Obe <<a href="mailto:lr@pcorp.us">lr@pcorp.us</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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" rel="noreferrer" 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" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/postgis-devel</a><br>
</blockquote></div>