Changes between Version 20 and Version 21 of PostGISExtensionPaths


Ignore:
Timestamp:
Jul 29, 2022, 10:33:40 PM (21 months ago)
Author:
strk
Comment:

Mark solution 1 as failing, with ticket reference

Legend:

Unmodified
Added
Removed
Modified
  • PostGISExtensionPaths

    v20 v21  
    2020
    2121
    22 == SOLTUION 1 ==
     22== SOLUTION 1 (FAILS) ==
    2323
    2424This has already been committed in master branch for PostGIS 3.3.0.
     
    3232What it does:
    3333Update the current version to ANY and then run the updates.
    34 This has the affect of always forcing the  postgis--ANY--<current version>.sql script to run which handles all versions.
     34This has the affect of always forcing the  postgis--ANY--
    3535
    36 Benefits of this approach:
    37 
    38 1. We only need to ship one extension upgrade script file per extension.  The postgis--ANY--<current version>.sql
    39 2. No clutter of 100s of 1000s of files.
    40 3. We don't need to maintain extensions/updateable.mk and remember to update it.
    41 4. It is possible to upgrade from postgis (older PostgreSQL Version) 3.3.0 to (new PostgreSQL version)  3.3.0. This is generally what is needed in pg_upgrade.
    42 
    43 **Drawbacks:**
    44 
    45 1. People can only upgrade using
    46 
    47 ```
    48 SELECT postgis_extensions_upgrade();
    49 ```
    50 Or do the manually mock with the pg_catalog.pg_extension table themselves
    51 
    52 2. We are mucking with system tables, pg_catalog.pg_extension, which we have done for other things, but is a questionable practice.
    53 
    54 3.  Packagers who have put in nice features to auto upgrade extensions during pg_upgrade, now have to treat us as special snowflakes.
    55 
    56 
     36BLOCKER: this solution does not work in some cloud environments, see https://trac.osgeo.org/postgis/ticket/5194
    5737== SOLUTION 2 ==
    5838