[postgis-devel] PSC Vote: Change PostGIS library name to drop the minor
Regina Obe
lr at pcorp.us
Tue Sep 5 11:27:04 PDT 2017
> Sure, I understand this. But reiterating my point from a previous email, pg_upgrade exists to update any on-disk binary changes and internal APIs. The assumption is that all other external libraries will remain the same,
> however I'm uncertain exactly what "the same" means in PostgreSQL terms.
Note sure what you mean by internal apis. Pg_upgrade only cares that the C functions bound to SQL functions still exist. It doesn't care about any other.
What Tom was proposing is if you really want to get rid of a function that is referenced in an SQL function (other internal functions are irrelevant since they have no public face as far as PostgreSQL is concerned)
Keep it around but have it throw an error. So people who don't run
ALTER EXTENSION postgis UPDATE;
Will have a broken function but they can still upgrade.
Or we could version out old functions. Like say one day Paul decided, cause he gets bothered by names, he doesn't like any of the function names we have. It's bugged him for quite some time the inconsistency and he's got to do something about it now.
He could in 2.5
Create a file called -- functions_pramsey_does_not_like.c - add all the function names he hates, link them to the new names he likes. He can have then throw an error if he chooses to be mean or just keep them working pointing at the good name.
Change all the SQL functions to point at functions_names_pramsey_prefers.c
Come PostGIS 3.0. Delete functions_pramsey_does_not_like.c and we are done.
Get it.
> ATB,
> Mark.
> For example if PostgreSQL 10 makes a binary change to the Datum struct or the AnalyzeStats struct compared to 9.6 then there is nothing we can do about this without a recompile, and I can't see how dropping the minor
> version would help here. So from what you are saying above, does that mean such a breaking change has taken place between 9.6 and 10?
Again not following you here. For every PostgreSQL version there is always a recompile. Our PostGIS 2.4.0 for PostgreSQL 9.5 and below isn't even the same as the PostGIS 2.4.0 we have for >= 9.6
Heck our PostGIS 2.4.0 if we choose to support PostgreSQL 11 is going to have all sorts of IF DEF this cause PostgreSQL 11 already doesn't work against PostGIS 2.4.0 and their datum stuff has changed already.
So yah we are constantly making little IF DEFS to handle apis that are new apis , and trying to keep old apis to support old versions. need to support long deprecated apis etc. We are frightened of using anything new cause we might break an old install.
PostgreSQL expects the library was compiled for PostgreSQL 10 and pg_upgrade expects to find all c functions referenced in the SQL functions of the database so when it runs CREATE FUNCTION it doesn't break.
Here is a corner case I have that I think is one Tom was talking about similarly why they don't do CREATE EXTENSION.
In postgis geocoder I changed one of the datatypes to add a new column. If you happened to have data tied to that data type and pg_upgrade were to do blindly
CREATE EXTENSION postgis_tiger_geocoder;
Your data could not be loaded because the data you had doesn't match with the new definition of norm_addy.
So the best thing for pg_upgrade to do is what it does -- bring over the type as it was.
When
ALTER EXTENSION postgis_tiger_geocoder UPDATE;
Is run, it would recognize you have the old data type definition and upgrade it including your data that references that type.
You can imagine the same thing with PostGIS. We define some type -- people god forbid starting using it in there data aka geometry / geography / raster /topology whatever.
We decide to add something to that type. Doing CREATE EXTENSION would screw up your data.
But conceivably pg_upgrade bringing over the type as it was -- our ALTER EXTENSION .. should recognize type is old format and with a
ALTER TYPE ... CASCADE fix up all your data and the functions in one go.
Hope this clarifies and not confuses the matter more,
Thanks,
Regina
More information about the postgis-devel
mailing list