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

[Stephen Frost]

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

> Either install 2.3 on 9.4 *or* 2.2 on 9.5 before pg_upgrading
> would make the current `pg_upgrade` process succeed.

Right, I get that.

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

> But both procedures, although giving a successful `pg_ugprade` run,
> leave all the database in a non-correct state, as
> `postgis_full_version()` should report from now (2.4.0) on.

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?

> This is because scripts that were built for PostgreSQL 9.4 are not
> necessarely full featured when used against PostgreSQL 9.5 (think
> parallel-safe, for a more recent change).

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

> > What checking would it do, exactly?  I'm sure we'd be open to adding
> > additional checks into pg_upgrade to ensure a successful upgrade.
> 
> I think an upgrade is really only finalized after ALTER EXTENSION
> is called on the new cluster. Even if re-sourcing the postgis enabler
> scripts for the *same* PostGIS version (which requires an hack,
> currently).

Ok, I understand your point here, but that isn't something that
pg_upgrade can check for.

> It's probably easier to visualize if the PostgreSQL version was
> embedded in the PostGIS version (as you do for packages):
> imagine it was not called "postgis-2.3" but "postgis-pg95-2.3"
> after pg_upgrade the result is "half-broken" in that "postgis"
> version is still at "pg93-xx".

This doesn't really make sense to me.  Perhaps I can be a bit more
explicit:

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

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.

> > > Or allow dropping the initial check (as I think you can still run
> > > ALTER EXTENSION UPDATE while missing the old .so file, right?)
> > 
> > This would depend on exactly what the extension and the
> > ALTER EXTENSION UPDATE script does.
> 
> Could this be advertised by the extension in the .control file ?
> Ie: something to invoke on each database containing the extension
> at the end of pg_upgrade.

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 that people would really see a successful pg_upgrade being
> > returned but not having a resulting functional system until an
> > ALTER EXTENSION UPDATE is done as really being a step forward either,
> > even if it could be guaranteed to work.
> 
> 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..?

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

Thanks!

Stephen
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20170830/7589e2c0/attachment.sig>