[postgis-devel] Rework extension upgrade paths to reduce proliferation

[Regina Obe]

I just thought of a more likely scenario where this breaks.

You can't pg_upgrade if you only installed the new version in your new PostgreSQL.
We would have gone thru all the trouble of dropping the minor in the lib file, 
only to now have an issue with scripts having to be symlinked since your old common script needed to move to the new version is non-existent in your new install.


-----Original Message-----
From: Regina Obe [mailto:lr at pcorp.us] 
Sent: Monday, August 19, 2019 1:27 PM
To: 'PostGIS Development Discussion' <postgis-devel at lists.osgeo.org>
Subject: RE: [postgis-devel] Rework extension upgrade paths to reduce proliferation

I think I'm beginning to get it and I see a tiny problem:

So  if we are shipping 3.0.0alpha6

Then we'd have
3.0.0alpha6 -- common  (no op)
common -- 3.0.0alpha6  (true upgrade)

If you had 3.0.0alpha5 installed then you'd have already in place
3.0.0alpha5 -- common (no op)
common -- 3.0.0alpha5 (true upgrade)


So PostgreSQL would follow the path:

3.0.0alpha5 -- common -- 3.0.0alpha6 
Running scripts (3.0.0alpha5 to common  and common -- 3.0.0alpha6)

That works assuming we still have the 3.0.0alpha5 scripts lying around.  But if the user (or package maintener) uninstalls 3.0.0alpha5 then how does this work?
There seems to be no path to get to alpha6 now.



-----Original Message-----
From: Regina Obe [mailto:lr at pcorp.us] 
Sent: Monday, August 19, 2019 1:07 PM
To: 'PostGIS Development Discussion' <postgis-devel at lists.osgeo.org>
Subject: RE: [postgis-devel] Rework extension upgrade paths to reduce proliferation

Not following what you are saying

What is <ver> in the case of say 3.0.0alpha3dev



-----Original Message-----
From: postgis-devel [mailto:postgis-devel-bounces at lists.osgeo.org] On Behalf Of Sandro Santilli
Sent: Monday, August 19, 2019 12:56 PM
To: postgis-devel at lists.osgeo.org
Subject: [postgis-devel] Rework extension upgrade paths to reduce proliferation

As of today, on my system, pg_extension_update_paths('postgis')
returns 9120 rows. And this is with just 17 versions of postgis installed [1]. Despite this crowd... I cannot upgrade PostGIS
because:

  ERROR:  extension "postgis" has no update path from version "3.0.0alpha3dev" to version "3.0.0alpha5dev"

So... I was thinking, since we already cheat with PostgreSQL in order to do the upgrade-to-same-version (using the "<curr>--next" and "next--<curr>" upgrade paths), how about dropping the "<curr>" portion of those upgrade paths and always provide, for each version, the following upgrade paths:

    <ver>-common
    common-<ver>

By doing that, we should be able to always only install a single pair of upgrade paths for every release (I'd have 34 instead of 9120 files) and there would always be an upgrade path between any two version:

   <ver1>--common -->  common--<ver2>

The <ver>--common upgrade path does not even need to contain any real upgrade as it would only be used to cheat PostgreSQL into believing we stepped to a new version. The common-<ver> should contain code to prevent attempts to downgrade or similar.

How do you like this idea ?


[1] select * from (select (pg_available_extension_versions()).*) foo
    where name = 'postgis';

--strk; 

  ()   Free GIS & Flash consultant/developer
  /\   https://strk.kbt.io/services.html
_______________________________________________
postgis-devel mailing list
postgis-devel at lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/postgis-devel