Use of deprecated function

[postgispaul]

St_Extend uses the deprecated function st_combine_bbox Postgis version 2.3.2, Postgres version 9.6.1

[robe]

This looks to be fixed already for ST_Extent. It was changed in PostGIS 2.2.0 the notes say.

-- Availability: 1.2.2
-- Changed: 2.2.0 to use non-deprecated ST_CombineBBox (r13535)
-- Changed: 2.3.0 to support PostgreSQL 9.6
-- Changed: 2.3.1 to support PostgreSQL 9.6 parallel safe
CREATE AGGREGATE ST_Extent(geometry) (
	sfunc = ST_CombineBBox,
  stype = box3d,
#if POSTGIS_PGSQL_VERSION >= 96
	combinefunc = ST_CombineBBox,
	parallel = safe,
#endif
	finalfunc = box2d
	);

I checked the current databases I have one running PostGIS 2.2.2 (I forget what I upgraded it from) and one 2 running PostGIS 2.3.2. All have ST_CombineBox (not ST_Combine_bbox).

So I suspect what you have here might be an upgrade issue. I think our current upgrade drops aggregates as needed, though I haven't tested that before. In past we would just always drop and recreate aggregates.

Also I assume your ST_Extend is a typo and you meant ST_Extent. I'm going to dismiss this.

[postgispaul]

I know it's been a while, but now I'm able to really check what's going on. Now I've updated the lot to postgres 10 and postgis 2.4.2 and still have the same issue. If I install a new cluster with postgres 10 and postgis 2.4.2 it works without warning, so indeed it's an update issue. I'm not able to remove postgis and add a fresh one (a lot of geometry is used), and I'm a bit worried that I'm missing some more bugfixes than this one. Is there a way to redefine all functions to their newest spec? Also, I have tried to find where the ST_Extent function is defined (so I can patch it manually) but I wasn't able to find it's definition...

P.S. and you're right about the typo :)

[robe]

What are you using for viewing. In pgAdmin the aggregates show under aggregates section, not functions.

What are you upgrading from.

And you did the

ALTER EXTENSION postgis UPDATE;

dance for sure?

What does:

SELECT postgis_full_version();

return for you?

There is a trick to force aggregates to upgrade. I think aggregates and types are the only things we rely the update message to know whether to upgrade or not because they could destroy user created things. Functions are always recreated, so they should all be fine.

[postgispaul]

I use pgadmin III for viewing the database, but I can't find any section about aggregates. I've been upgrading postgis for quite some time now, so I don't exactly know what the first installed version was, but this time I upgraded from 2.3.2, did all the steps for upgrading (incl alter extension update) and postgis_full_version returns:

"POSTGIS="2.4.2 r16113" PGSQL="96" (procs need upgrade for use with "100") GEOS="3.6.2-CAPI-1.10.2 4d2925d" PROJ="Rel. 4.9.3, 15 August 2016" GDAL="GDAL 2.2.2, released 2017/09/15" LIBXML="2.7.8" LIBJSON="0.12" LIBPROTOBUF="1.2.1" RASTER".

If you have a pointer on how to forcibly upgrade aggregates (is this possible after upgrading postgis itself?) I would very much appreciate it

[strk]

POSTGIS="2.4.2 r16113" PGSQL="96" (procs need upgrade for use with "100")

The above means that the version of your PostGIS scripts were built for PostgreSQL 9.6 while they are being used in a PostgreSQL 10. The way to fix this would be to rebuild PostGIS against the correct PostgreSQL version and then force-upgrade as you mention.

To force-upgrade, if you installed PostGIS as an extension you'll have to do:

 ALTER EXTENSION postgis UPDATE to 2.4.2next;
 ALTER EXTENSION postgis UPDATE to 2.4.2;

[postgispaul]

Tried that, now postgis version gives this: "POSTGIS="2.4.2 r16113" PGSQL="100" GEOS="3.6.2-CAPI-1.10.2 4d2925d" PROJ="Rel. 4.9.3, 15 August 2016" GDAL="GDAL 2.2.2, released 2017/09/15" LIBXML="2.7.8" LIBJSON="0.12" LIBPROTOBUF="1.2.1" RASTER"

but still the deprecation message...

[strk]

Ah yes, now I read the actual ticket. Ok, the upgrade script will only update that aggregate IFF upgrading from version 2.3.0 or lower, or if upgrading between 2.3.0-dev versions.

How you ended up in 2.3.2 with no upgrade I don't know, but I know there are a lot of other things that would not upgrade anymore if they didn't upgrade when it was time for it.

Maybe you could try, as an hack, to _pretend_ your installed postgis version is < 2.3.0 buy overriding the postgis_scripts_installed function. You'd do something like this:

BEGIN; -- do in a transaction, to rollback on failure
CREATE OR REPLACE FUNCTION postgis_scripts_installed() RETURNS text
  AS $$ SELECT '2.3.0'::text || ' faked (real version is 2.4.2 r16113)' AS version $$
  LANGUAGE 'sql' IMMUTABLE;

Then you can check postgis_full_version(), just for fun, and then cross your fingers and proceed to:

 ALTER EXTENSION postgis UPDATE to 2.4.2next;

If everything went smooth you can then update again to 2.4.2 and finally commit, otherwise let us know what goes wrong.

[postgispaul]

Ok, after changingthe postgis_scripts_installed to return 2.2.0 and do the alter extension commands the st_extent uses the correct st_combinebbox

So thanks!, it's finally solved