[postgis-tickets] [PostGIS] #4334: Can't upgrade with a view based on ST_AsMVTGeom

[PostGIS]

#4334: Can't upgrade with a view based on ST_AsMVTGeom
------------------------------------+---------------------------
  Reporter:  Algunenano             |      Owner:  Algunenano
      Type:  defect                 |     Status:  new
  Priority:  high                   |  Milestone:  PostGIS 3.0.0
 Component:  build/upgrade/install  |    Version:  2.4.x
Resolution:                         |   Keywords:
------------------------------------+---------------------------

Comment (by Algunenano):

 This also applies to aggregates, for example a view over the ST_Makeline
 aggregation also breaks:

 {{{
 cannot drop function st_makeline(geometry) because other objects depend on
 it
 }}}

 This aggregation is being dropped unconditionally since 2.5:
 {{{
 $postgis_proc_upgrade$;
 -- Aggregate ST_MakeLine (geometry) -- LastUpdated: 205
 DO LANGUAGE 'plpgsql'
 $postgis_proc_upgrade$
 BEGIN
   IF 205 > version_from_num OR (
       205 = version_from_num AND version_from_isdev
     ) FROM _postgis_upgrade_info
   THEN
     EXECUTE 'DROP AGGREGATE IF EXISTS ST_MakeLine (geometry)';
     EXECUTE $postgis_proc_upgrade_parsed_def$ CREATE AGGREGATE ST_MakeLine
 (geometry) (
         SFUNC = pgis_geometry_accum_transfn,
         STYPE = internal,
         parallel = safe,
         FINALFUNC = pgis_geometry_makeline_finalfn
         );
  $postgis_proc_upgrade_parsed_def$;
   END IF;
 END
 $postgis_proc_upgrade$;
 ```

 The exact same issue for ST_Collect:
 ```
     cartodb_user_d404665e-f81e-49c3-a4f2-86d7b3a96f24_db
 }}}

 {{{
 -- Aggregate ST_Collect (geometry) -- LastUpdated: 205
 DO LANGUAGE 'plpgsql'
 $postgis_proc_upgrade$
 BEGIN
   IF 205 > version_from_num OR (
       205 = version_from_num AND version_from_isdev
     ) FROM _postgis_upgrade_info
   THEN
     EXECUTE 'DROP AGGREGATE IF EXISTS ST_Collect (geometry)';
     EXECUTE $postgis_proc_upgrade_parsed_def$ CREATE AGGREGATE ST_Collect
 (geometry) (
         SFUNC = pgis_geometry_accum_transfn,
         STYPE = internal,
         parallel = safe,
         FINALFUNC = pgis_geometry_collect_finalfn
         );
  $postgis_proc_upgrade_parsed_def$;
   END IF;
 END
 $postgis_proc_upgrade$;
 }}}

 I guess this was done because it was considered simpler that updating
 postgresql system tables.

 As with the previous issue, since this is executed with every update it's
 an infinite issue, but the good thing is that starting from PG12 this
 could be changed by `CREATE OR REPLACE` without dropping anything.

-- 
Ticket URL: <https://trac.osgeo.org/postgis/ticket/4334#comment:9>
PostGIS <http://trac.osgeo.org/postgis/>
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.