Changes between Version 15 and Version 16 of PostGISExtensionPaths

Timestamp:

02/11/22 11:41:10 (3 years ago)

Author:

robe

Comment:

--

PostGISExtensionPaths

@@ -82 +82 @@
 === SOLUTION 3 ===
 
-The 0-byte file and strip model.  This approach creates 0 or very small byte files, with their existense solely to maintain PostgreSQL extension chain model.
-Still up for discussion: **To reduce file bloat, we will have <version-minor>.X--<version-minor-current> files**.  
-We will keep 2 micros before for each minor, just in case the user uninstalled the prior minor before installing the new one.
+The 0-byte file model.  This approach creates 0 or very small byte files, with their existence solely to maintain PostgreSQL extension chain model.
 
 
-The assumption is anyone coming from a prior minor will have a file such as postgis--3.2.1--3.2.X version OR use the postgis_extensions_upgrade() function.
-
-In this model, our generated extension upgrade scripts will look like the below, with only the postgis--3.3.X--3.3.0.sql having any upgrade statements in it.
+In this model, our generated extension upgrade scripts will look like the below, with only the postgis--3.3.X--3.3.0.sql having any upgrade statements in it and the others being 0-byte or miniscule with a comment or no-op command.
 
 ----
 {{{
 :
+postgis--3.0.1--3.3.X.sql
+postgis--3.0.2--3.3.X.sql
+postgis--3.0.3--3.3.X.sql
 postgis--3.0.4--3.3.X.sql
 postgis--3.0.5--3.3.X.sql
-postgis--3.0.X--3.3.X.sql
+postgis--3.1.1--3.3.X.sql
+postgis--3.1.2--3.3.X.sql
+postgis--3.1.3--3.3.X.sql
 postgis--3.1.4--3.3.X.sql
 postgis--3.1.5--3.3.X.sql
-postgis--3.1.X--3.3.X.sql
 postgis--3.2.0--3.3.X.sql
 postgis--3.2.1--3.3.X.sql
-postgis--3.2.X--3.3.X.sql
 postgis--3.3.X--3.3.0.sql
-postgis--3.3.0--3.3.X.sql
 }}}
 ----
@@ -110 +108 @@
 
 1. We are staying between the lines. Respecting known practices, but still having much lighter weight scripts.
-2. A little less clutter, but we are relying on the user having the old version still installed (or being within 2 micro versions of the last minor they have installed) so that they have a chain 
-postgis--<old-version-minor>.X--<old-version-minor-verson>.sql
-3. An easier release cycle since extensions/updateable.mk doesn't need to list the prior micros.
-4. No change in upgrade extension workflow for packagers (or users who think of PostGIS as any other extension).
-5. It will work for all PostgreSQL versions supported
+2. No change in upgrade extension workflow for packagers (or users who think of PostGIS as any other extension).
+3. It will work for all PostgreSQL versions supported
 
 ** Downsides:**
 
-1. We still have some clutter of files, and without addendum, we have just as much clutter of files as before.
-2. With addendum, it is not possible for a user to upgrade using ALTER EXTENSION from a version we don't ship a script for. They would have to use and that assumes this version -- has the ANY/MAX hack.
+1. We still have the same useless clutter of files.
 
-----
-SELECT postgis_extensions_upgrade();
-----
-
-3. It is not possible to upgrade from version (prior PostgreSQL version) 3.3.0 to (newer PostgreSQL version) 3.3.0 which is needed often in pg_upgrade to gain the benefits of new features in latest PostgreSQL version that are not exposed in older PostgreSQL versions.  Such operation would just state "You are already at latest version" and not do anything, unless one does it via 
+2. It is not possible to upgrade from version (prior PostgreSQL version) 3.3.0 to (newer PostgreSQL version) 3.3.0 which is needed often in pg_upgrade to gain the benefits of new features in latest PostgreSQL version that are not exposed in older PostgreSQL versions.  Such operation would just state "You are already at latest version" and not do anything, unless one does it via 
 
 ----