[postgis-devel] Upgrade paths (again)

[Regina Obe]

> Maybe then I should add a parameter the `install-upgrade-from-available`
> being the path to one (or more?) extension directories to scan for
> determining which versions of postgis to consider "available". Would that
> help ?
> 

I have no faith in users knowing what to do.  They barely know how to run
ALTER EXTENSION or postgis_extensions_upgrade(). I have no faith in myself
knowing what to do.

For the most part apt.postgresql.org walks me thru pg_upgradecluster very
nicely (when doing beta to rc to production) actually (shout out to
Christoph Berg and Bas Couwenberg). and when you run it manually, it
specifies a from target to a final target. To make this bareable for users,
you'd have to have pg_upgradecluster run this as part of the upgrade.  But
then what about the regular old installs where you are just doing
micro-upgrades?  The scripts still need to be there, so that again would
force packagers to inject this run in their install process. Their process
often is to uninstall the old, so again the scripts don't exist you need to
upgrade, unless they jury rig their install process fighting a chicken and
egg battle.

> > On windows I don't think that would work at all, as I presume your
> > script is perl based and I don't assume perl is installed as a
> > requirement. Might work for other packagers.
> 
> Ehm, when I started it it was in shell, rewrote it in Perl becuase you
guys
> complained that Windows would need Perl. Now Perl isn't good either ?
> 
Yah bash/sh definitely doesn't work.  I think the issue was with
postgis_restore which was not usable at all under windows, so for windows
users, it was 
"Install Perl"

Or 

Just do a dump /restore and deal with the junk left over.  That is less of a
concern, since there is no junk left over with CREATE EXTENSION approach.

No windows user I know of but me has Perl installed and even then, I only
have it under Mingw64/Msys2 where I have shell anyway.  Windows servers are
pretty bare.  Many systems I've been on have even barred Powershell from
running.

> > I still liked your old fix better, as it worked for most users except
> > for sandboxed systems.  This new solution seems to have too many warts.
> >
> > I still preferred Paul's solution most of all, cause I think you can
> > set up a round-robin to do a micro upgrade and it worked for all.
> 
> Could you expand on this ? I belive my solution is BASICALLY the same of
> Paul's, just with a different naming and a broader (least safe?).
> 
> With my patch (as with Pauls' solution) we'll be installing, for all
future
> releases, an upgrade path going from there to ANY.
> 
> The need to still install upgrade paths ONLY exists for being able to
upgrade
> from OLDER releases, basically.
> 
> > We would have
> > just one script per minor version and postgis_extensions_upgrade()
> > would handle the micro update of springing between UPGRADEME and
> back.
> 
> In my solution we would have just one script AT ALL and
> postgis_extensions_upgrade handles the micro updates too (did you really
try
> it?)
> 
No haven't tried it yet, so I should probably do that before babbling about
what I think you are doing :)  Still working on CI  stuff.
Does it do micro micro updates?  Like PostgreSQL 15 3.3.0dev to PostgreSQL
15 3.3.0dev  or PostgreSQL 12 3.3.0 to PostgreSQL 15 3.3.0?

> > Though it would require running postgis_extensions_upgrade() twice,
> > which Darafei's proposal of making that a procedure would resolve.
> 
> This is a separate issue and please someone file a ticket for it :)
> 

Okay I'll ticket and slate for 3.4.0 maybe call it something different so we
have some backward compatibility.   It's so annoying that procedures have to
called with below so would be backward breaking if we kept the name.
CALL postgis_extensions_upgrade();