[postgis-devel] Upgrade paths (again)

[Greg Troxel]

Sandro Santilli <strk at kbt.io> writes:

> In this model we'd install 0-byte files going to an unspecified
> version (ANY), and a real upgrade script going from an arbitrary
> version to the current.
>
> PostGIS would then always install 2 upgrade paths:
>
>     <version>--ANY    ( empty )
>     ANY--<version>    ( actual upgrade script )
>
> The above 2 files would ALWAYS allow hitting our single upgrade script
> by updating to ANY and then to the target version.
>
> The postgis_extensions_upgrade() script, rather than modifying system
> catalogs as it does now, would simply UPDATE TO 'ANY' prior to UPDATE
> to the target version (rather than directly touching system catalogs).
>
> The problem of NEEDING to install upgrade paths for ANY POSSIBLE
> postgis extension version installed kind of remains unsolved
> even if it's more of a packaging issue than a postgis installation
> issue. What we could do is provide some administration command
> (re-using the existing "postgis" command, for example?) to install
> the <version>--ANY upgrade paths for specific arbitrary versions
> of PostGIS or for those found to be used in databases of a given
> cluster, something like:
>
>   loader/postgis install-upgrade-path-from <version>
>   loader/postgis install-upgrade-paths-for <database>
>
> Comments ? Especially from packagers, as the loader/postgis would
> then possibly need to be called at upgrade time to figure out what's
> needed...

I must confess that I have never really understood this.

When I read
  https://postgis.net/docs/manual-3.2/postgis_administration.html#upgrading
I don't really understand
  - how that relates to this discussion
  - what packaging system should do, if anything, when
    * replacing postgis 3.1.x with 3.2.x
    * changing from pgsql 12 with postgis 3.2 to pgsql 13 with postgis 3.2
    * changing from pgsql 12 with postgis 3.2 to pgsql 13 with postgis 3.3
  - what a package manager should do if pgsql is not running when the
    above upgrades happen  (pkgsrc typically doesn't do a lot of this,
    and leaves the user to dump/restore across postgresql version
    changes, i.e. dump, nuke db dir, upgrade, restore.
  - how many people have postgis installed "without extensions" vs
    "with"
  - how to change from "without" to "with"
  - what to type to find out which you have



If what you mean is:
  - we'll have the same set of (increasing number of ) files
  - most of them will be 0-byte files

then for me it is an unimportant change.  Right now a few of them have
content and many are symlinks.

I realize Windows doesn't really support symlinks in a reasonable way,
and presumably this "duplicated files" is a Windows-only concern.  If
that's off base, please straighten me out.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20220730/c9d3f697/attachment.sig>