[postgis-devel] Separate make target to install extension upgrade scripts ?

[Regina Obe]

> 
> Most of this mess stems from the Original Sin of having a versioned .so
file,
> which in turn necessitates a Huge Upgrade, as all the existing functions
need to
> be re-pointed to the new versioned so. 

That well is not really the case anymore.  Our .so at least for production
usage is
going to be at postgis-3.so for probably another 10 years.

So yah for functions we know we didn't add or change, we could just drop
those from upgrade scripts if we wanted to go the little-bitty versioned
script route. This assumes that we record we changed them.  Something we
sometimes miss, and that missing could be devastating using the little-bitty
version script route.

So I think we've  passed that problem.
It's only a problem for "DEVELOPERS" who choose to use the --include-minor
switch and our lack of discipline.


If we had immediately decided "there
> will be only one version of postgis per pgsql cluster" we could have moved
to
> incremental upgrade scripts and generally had a much more pleasant life.
As it
> stands now, it feels like the hole we have been digging is 100 feet deep
and I
> cannot even see the sky anymore.
> 
> P

I tend to feel even in hindsight that wouldn't have worked out too well.
Upgrading PostgreSQL clusters is way scarier than upgrading PostGIS in my
opinion, especially now.
Everytime I upgrade PostgreSQL I've got to get a new set of database
drivers, test for weird corner cases.  Much less an issue with PostGIS
upgrades.

One possible mistake I felt we did make, is if we are going to offer a new
feature that a newer PostgreSQL version showcased (I'm thinking BRIN SPGIST
etc), we should have dropped support of all the other versions of PostgreSQL
in that new release.  That would be kind of getting to where you want to be.

But can you imagine all the users screaming how they can't have a new
PostGIS because they are stuck on an old PostgreSQL version?  So perhaps we
did the right thing.
Hey I'm on centos 7 and running a fairly modern PostGIS on a PG11, I'm so
grateful for that. Because the PostGIS version is more important to me for
many cases than is the PG version, and I know if I upgrade my PG version,
I'm bound to break a bunch of apps, I don't have time to debug right now.

I think it would have slowed PostGIS adoption doing that.
Plus we have still a ton of plpgsql that needs upgrading.

The only issue we have now is requiring too many extension upgrade scripts.
Having itty-bitty scripts is not going to change that problem.

We'd still have a lot of extension upgrade scripts.  I have nightmares of
scripts chasing me.  I want all those scripts gone or at least reduced down
to 1 per minor upgrade.

I'm also disgusted at looking at other people's upgrade extension scripts.
Seems like a nightmare to keep track of.  There is no way we are going to be
doing that even if we were doing it "THE RIGHT WAY".  Think about all the
crazy changes we do.
Think about people's half broken systems (admittedly problems we caused
which we had to fix in later releases, but we could because we had control
of how to fix the "Not quite at 3.1" problem).  There is no way to fix them
assuming that they are at some version they are not on.

Only solutions and I've said it before, which is fix extension management
upstream (my ideal hope) so we have more flexibility on what scripts to run
or we ditch these annoying micro releases. I mean we can have micros, but
not have any plpgsql change in them and keep the extension version at 3.4
(not 3.4.0 and stuff, people can look at the lib version if they need that
detail).
But Darafei and Strk didn't like that idea.  Something about developer
freedom to change plpgsql functions.