[postgis-devel] Upgrade paths (again)

[Sandro Santilli]

On Fri, Aug 12, 2022 at 02:06:16PM -0400, Regina Obe wrote:

> So you are proposing packagers run this as part of their install process,
> not as part of packaging?

Yes

> 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.

I don't have much experience with these packages but last time I used
one (deb package) it did *hint* me about using pg_upgrade but didn't
do it automatically for me.

>  So you can't be looking at the cluster you are
> installing to.  You have to look at the cluster you are coming from.

True!
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 ?

> 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 ?

> 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?)

> 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 :)

--strk;