[postgis-devel] Upgrade paths (again)

[Regina Obe]

> > This only seems useful to end users that compile their own PostGIS, or
> > am I missing something.
> 
> I'd say it's generally useful also to system administrator, who knows
which
> versions of PostGIS were ever installed on the system.
> 
Yes

> And to package management systems, to run BEFORE getting rid of the old
> packages, to ensure no upgrade path is ever left uncovered ?
> 
> A packager is not going to know which versions a user has installed,
> > and likely doesn't even have anything installed in their PostgreSQL
install.
> 
> The package managers I know of have the ability to run a script before or
> after doing "things". Don't knot the details but they do things like
setting
> symlinks or starting interactive configuration sessions.
> 
> They may as well run that script.
> > And for such a user, they most likely can update their system catalogs
> > fine, so your original solution committed to PostGIS 3.3.0 still seems
> > more straightforward and useful.
> 
> I love my original solution (messing with catalogs) but we found that to
be not
> viable on cloud systems and I'm trying to find a solution for that (this
is similar
> to Solution3 on the wiki)
> 
> --strk;

So you are proposing packagers run this as part of their install process,
not as part of packaging?
The problem I see with this is in most cases when you go from a PostGIS
minor to a PostGIS minor, whether that be cloud or just regular Linux, you
are also doing a pg_upgrade.  So you can't be looking at the cluster you are
installing to.  You have to look at the cluster you are coming from.

Most Linux distros (except for yum.postgresql.org) offer only one minor
version of PostGIS for each major version of PostgreSQL.  So your old
scripts that tell you what version you installed, are on the old cluster,
not the new cluster.  Your new cluster is going to see nothing installed,
and thus will not install any scripts.

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.

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.  We would have
just one script per minor version and postgis_extensions_upgrade() would
handle the micro update of springing between UPGRADEME and back.

Though it would require running postgis_extensions_upgrade() twice, which
Darafei's proposal of making that a procedure would resolve.

Thanks,
Regina