id summary reporter owner description type status priority milestone component version resolution keywords cc 4334 Can't upgrade with a view based on ST_AsMVTGeom Algunenano Algunenano "{{{ cartodb_dev_user_3e4a6fc6-4137-4c59-bc63-066f80efb90e_db=# alter extension postgis update TO ""3.0.0devnext""; ERROR: cannot drop function st_asmvtgeom(geometry,box2d,integer,integer,boolean) because other objects depend on it DETAIL: view mvt depends on function st_asmvtgeom(geometry,box2d,integer,integer,boolean) view ""Building"" depends on function st_asmvtgeom(geometry,box2d,integer,integer,boolean) view aaaaaaaaaaa depends on function st_asmvtgeom(geometry,box2d,integer,integer,boolean) view aaaaa depends on function st_asmvtgeom(geometry,box2d,integer,integer,boolean) HINT: Use DROP ... CASCADE to drop the dependent objects too. }}} postgis_upgrade.sql does this: {{{ DROP FUNCTION IF EXISTS ST_AsMVTGeom(geom geometry, bounds box2d, extent int4, buffer int4, clip_geom bool); [...] CREATE OR REPLACE FUNCTION ST_AsMVTGeom(geom geometry, bounds box2d, extent int4 default 4096, buffer int4 default 256, clip_geom bool default true) RETURNS geometry AS '$libdir/postgis-3','ST_AsMVTGeom' LANGUAGE 'c' IMMUTABLE PARALLEL SAFE; }}} Since the 2 signatures are the same, it's trying to drop the current ST_AsMVTGeom before doing the CREATE OR REPLACE, so the upgrade fails. I'm planning on checking the rest of the functions in postgis_drop_before.sql to confirm they aren't covering already existing functions like it's happening in ST_AsMVTGeom. I guess 2.4+ is affected by this." defect closed high PostGIS 3.0.0 build 2.4.x fixed komzpa