[postgis-devel] PSC Vote: Change PostGIS library name to drop the minor

[Sandro Santilli]

On Wed, Aug 30, 2017 at 10:49:28AM -0400, Stephen Frost wrote:
> * Sandro Santilli (strk at kbt.io) wrote:
> > On Wed, Aug 30, 2017 at 08:29:23AM -0400, Stephen Frost wrote:
> > > * Sandro Santilli (strk at kbt.io) wrote:
> > 
> > >  The alternative approach would be to install 2.2 on 9.5,
> > > then upgrade, and then upgrade PostGIS on 9.5 to 2.3, presumably that
> > > would be correct? 
> > 
> > Not yet, it's about the same.
> 
> I'm not sure I'm following.  If the ALTER EXTENSION UPDATE is done in
> 9.5 with 2.3 installed and being updated, wouldn't that do the update
> just as you're describing later on?

Yes, that will work, my fault I misread the process.
The only problem in that case would be PostgreSQL 9.5 cluster will
need to have access to a postgis-2.2.so at pg_upgrade time (beacuse
it checks it).

> > And both have the issue Regina is complaining about of adding
> > support for future PostgreSQL versions in old PostGIS branch or viceversa
> > (maintain support for old PostgreSQL versions).
> 
> Isn't that something you would want to be doing anyway..?

Possibly, but there must be an end-of-life at one point.

> Wouldn't the process of installing the older version of PostGIS into the
> newer PG version, then doing pg_upgrade, then doing ALTER EXTENSION
> UPDATE cause it to return the correct result?

Yes, adding the `ALTER EXTENSION UPDATE` should complete the upgrade.

> Understood, but isn't executing the UPDATE in 9.5 to move from 2.2 to
> 2.3 going to address that?

Yes!
And I think it would not even need access to the 2.2 .so (only
pg_upgrade insists in that).

> With both clusters installed and the necessary versions of PostGIS
> installed, we have these files:
> 
> /path/to/pg-9.3/lib/postgis-2.2.so
> /path/to/pg-9.5/lib/postgis-2.2.so
> /path/to/pg-9.5/lib/postgis-2.3.so

In the above scenario the upgrade should work.
I think what people are being hit by is lack of `/path/to/pg-9.5/lib/postgis-2.2.so`

How do you know you need that file, btw ?
Is it done transparently by package manager or user needs to take
care of that ?

> A pg_upgrade is done to go from 9.3 to 9.5.  At this point, things
> aren't entirely perfect because we're on 9.5 w/ PostGIS 2.2 with a
> 9.3-based PostGIS install, but more-or-less everything which *was*
> working under 9.3 should at least still work.  We need to be clear with
> users that they really need to then run ALTER EXTENSION UPDATE to bring
> it up to 2.3, but they run that under the 9.5 cluster and with the 2.3
> PostGIS as build for 9.5 and hopefully that all works.  I was simply
> trying to confirm that this results in a solid 9.5+2.3 installation.

I confirm the described procedure should result in a solid 9.5+2.3
installation.

> pg_upgrade can not run anything in the new cluster.  To do so would
> break the ability to "roll back" a pg_upgrade.  What could be done,
> however, is to have pg_upgrade spit out a "upgrade extensions" script
> (similar to the ANALYZE script that it produces) based on information
> from the .control files (or even just automatically when newer versions
> are found...).  Perhaps we could have specifics in the .control files
> that provide reasoning for why this is a good/necessary thing to do.

I'm not sure pg_upgrade would be able to figure out how to upgrade
an extension that doesn't change version (as in "postgis-2.2 for
PostgreSQL 9.3" vs. "postgis-2.2 for PostgreSQL 9.4").

> > I'm not sure there's a case of non-functional, but sub-optimal
> > exists for sure (for instance: <-> operator not based on real distance
> > when it's supposed to be).
> 
> That would be a bug fix which should be back-ported to all supported
> versions, shouldn't it..?

It's only supported by newer PostgreSQL, so even if you backport it
to oldest PostGIS version you still won't have that functionality
in an older PostgreSQL database (so won't be fixed by pg_upgrade).

As observed above, an "ALTER EXTENSION UPDATE <proper_target_here>"
would fix this case.

> If 2.2 is no longer receiving updates once 2.3 comes out, then that's an
> entirely different discussion that needs to be had, I think...

Also how to deal with longer upgrades, say from
PostgreSQL-9.0_PostGIS-2.0 to PostgreSQL-9.6_PostGIS-2.4:
will you still have postgis-2.0 .so in your postgresql-9.6-postgis-2.4
package ?

--strk;