[postgis-devel] PSC Vote: Change PostGIS library name to drop the minor
lr at pcorp.us
Mon Sep 4 15:08:34 PDT 2017
> The other particularly evil thought that occurred to me was do you need to have a real PostGIS 2.3? What if you were to generate a compatibility postgis-2.3.so with empty stub methods - would that be enough to be able to > remove the extension post-upgrade and then install the new version?
Creating a symlink from postgis-2.4 (compiled for PostgreSQL 10) and calling the link postgis-2.3
is a lot less evil I think.
In fact your PostGIS will still work after upgrade even if you don't rush to do
ALTER EXTENSION postgis UPDATE;
Because we did not remove any functions exposed via the SQL scripts. We only added functions.
You can even do this for postgis-2.2 and you'll be fine.
But as Darafei pointed out in the last comment
Many people just don't get that. It's a hard thing for people to fathom.
That you can take postigs-2.4 compiled for PostgreSQL 10 and call it postgis-2.3 PostgreSQL 10 and it will work.
postgis-2.3 compiled for PostgreSQL 9.6 CAN NOT BE USED by something looking for PostgreSQL 10 postgis-2.3
(though they both have 2.3 they are incompatible).
Thus my need to just ditch the minor to make every one's life easier.
A couple of things have happened, Mark since you were last very active that makes this more urgent.
1) pg_upgrade did not exist so most people just had to do a dump restore when going from one PostgreSQL version to another. Now people expect to be able to just use pg_upgrade without having to worry about having both versions of PostGIS installed.
2) In the past we ade a lot more crazy changes that did break ABI. I think we stopped doing that around 2.1 and are more careful.
3) PostgreSQL is changing a lot more than we are. We are using a whole bunch of deprecated APIs that are going to be pulled from under our covers.
We have to stop trying to support newer versions of PostgreSQL on older versions of PostGIS if we ever hope to keep up.
4) We've got DBaaS services that now offer PostGIS - Amazon RDS, Amazon Aurora, Google Cloud for PostgreSQL, Microsoft Azure for PostgreSQL
and many other smaller players.
As such you can expect more traction and a lot more people less sophisticated about DBA stuff.
I guess we can argue hosters can come up with their own crazy solutions to work around this and I'm sure they have already so 4 is a bit less of a concern.
More information about the postgis-devel