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

Regina Obe lr at pcorp.us
Wed Sep 6 11:16:30 PDT 2017


> On 06/09/17 18:40, Regina Obe wrote:

>> This nice feature of pgRouting we can't have because all our data is 
>> tied to PostGIS, so a DROP EXTENSION of postgis can not be done 
>> without losing your data.

> Right, especially as spatial datasets often have a tendency to be very large.

> I wonder if there is some possibility to mark various pg_types during CREATE TYPE as "SAFE" which means that if the type is removed via DROP TYPE, the data remains but the default input/output functions default back to 
> bytea? Then it wouldn't matter so much because you could always do a DROP EXTENSION, and then when the type is reintroduced with a subsequent CREATE EXTENSION then the new input/output functions would take 
> over and all would be well.


> ATB,

> Mark.

You'd need a little more than just the type stuff.

You see now that MATERIALIZED VIEWS are the new in-thing people have started stuffing expensive PostGIS aggregate functions into their views.  We had it before with regular views but now people have gone super crazy with materialized views.  pgRouting conveniently doesn't have to worry about that because much of their stuff takes SQL queries so stuffing it in a materialize view would defeat the purpose.  They also have no aggregates to worry about and for functions as long as you don't change the SQL API or arg names you can REPLACE without dropping first.

So I had to for example put in some shameful system catalog updates just because some guy begged us not to drop ST_Union and recreate ST_Union during upgrade because we needed to mark it parallel safe.
This is why we only drop/ recreate aggs in the first Minor (and try to avoid at all costs in micros).  This is why I don't like supporting things like 2.4 in PostgreSQL 9.4 because we have code preventing recreation and putting in the newer logic for this very reason.

Now if we had to change the transition functions the logic would be a little messier.


Thanks,
Regina








More information about the postgis-devel mailing list