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

[Regina Obe]

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