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

[Sandro Santilli]

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.

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

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

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.

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

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

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

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

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

--strk;