[postgis-devel] PSC Vote: Drop the minor in the postgis lib files

[Regina Obe]

> On Thu, Sep 27, 2018 at 12:52:57AM -0400, Regina Obe wrote:
> 
> > So are you okay with me pushing ahead with this?
> > As mentioned the default behavior is the lib file will be called
> > postgis-3.whatever, rtpostgis-3.whatever
> 
> Ok, let's see where does this take us.
> This means we CAN NOT drop or change any C-level signature used by
> PostgreSQL (we should mark them somehow) without updating the _major_
> version.
[Regina Obe] 
The plan is we would have a postgis_legacy.c, rt_legacy.c or some such thing that would just throw an error saying

"Please run ALTER EXTENSION postgis UPDATE;" 

For functions we want to drop and keep these till we go to 4.0

I already did this for raster and postgis in 2.5, because we took out pg_abs and a function in raster (renamed it)
That prevented the trick  of just symlinking to the new library for upgrade.

This I feel is something we need to be very cognizant of anyway because right now to run pg_upgrade you need to install both old and new 
or use symlink and symlink will not work unless we pay attention to not drop things.

> 
> > This also has the benefit that all the lib files will be kept in synch
> > so you don't end up with the disaster of running say an older
> > postgis_sfcgal , postgis_topology Than your postgis and backends of
> > liblwgeoms fighting with each other.
> 
> I don't understand what you mean here, can you explain ?
[Regina Obe] 
Okay imagine you have installed postgis_sfcgal and postgis in 2.4

In the current world if you just do 

ALTER EXTENSON postgis UPDATE;

Only your postgis functions would be upgrade to 2.5, and your postgis_sfcgal would still be at 2.4

You would have two backends returning  random confusing errors as they swap back and forth.
This was very much the case in 2.1, 2.2 and still exists.

In the new world, the so of both will end in 3  so your postgis_sfcgal would be partially upgraded when you install the 3.1 libraries.
PostGIS SFGAL would Upgraded enough so it doesn't mess your use of postgis and would only be an issue if we drop SFCGAL functions from postgis.

Even better, you could run for a bit (the functions you currently use) without running ALTER EXTENSION, so you could downgrade simply by uninstalling 3.1 and rerunning 3.0 install.

If we legacied some  functions and you called a function we legacies, you would immediately get an error -- .. NEED to run ALTER EXTENSION postgis_sfcgal UPDATE

Which would be way more clearer than current case of your function just not working cause you had uninstalled the older version of PostGIS thinking you didn't need it.

Same goes for postgis_topology right now it's possible for you to have two different liblwgeoms fighting with each other because you ran update on postgis but not postgis_topology.
The case is more serious now that we have postgis_raster as a separate extension. Now it's possible to have 3 liblwgeoms if you neglected to run ALTER EXTENSION and no way for us to inform you pre-3.0


I most reiterate about pg_upgrade -- sorry if I am repeating myself

In case where you use pg_upgrade to migrate to a newer PostgreSQL say going from PostgreSQL 11 PostGIS 3.0  to PostgreSQL 12 PostGIS 3.1, it would be a smooth ride.
No need to install older version to get newer version of PostGIS and should we have taken out a function, you'd get a very information "Please run ALTER EXTENSION ..." on the first call of said function.

The issue is even worse now say with if you are running PostgreSQL 9.1 2.0 and want to pg_upgrade to 11 2.5 - you need to install like 4 different versions of PostGIS and do two PostgreSQL hops because we don't support 9.1 in newer versions of postigs.

There would no longer be a need to install older PostGIS on your newer PostgreSQL.

pg_upgrade would work fine because we didn't remove C-API functions from the newer PostGIS 3.1 that were present in 3.0.
We CAN make them unusable by stubbing them with a helpful error "Please run ALTER EXTENSION ...."

But pg_upgrade would pass without having to do any symlink hacks and you'd get this error only when trying to use said function.

I'm thinking of bringing back all the functions we dropped between 2.0 and 2.2 so you can at least symlink to 3.0 and run a clean 

ALTER EXTENSION ... call.

Right now it's incredibly painful to upgrade a huge database coming from 2.0 -> present


Thanks,
Regina