Opened 2 years ago

Closed 2 years ago

Last modified 18 months ago

#3706 closed defect (worksforme)

Use of deprecated function

Reported by: postgispaul Owned by: robe
Priority: high Milestone: PostGIS 2.3.3
Component: postgis Version: 2.3.x
Keywords: Cc:

Description

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

Change History (10)

comment:1 Changed 2 years ago by robe

Milestone: PostGIS 2.3.3
Priority: mediumhigh

comment:2 Changed 2 years ago by robe

Owner: changed from pramsey to robe

comment:3 Changed 2 years ago by robe

Resolution: worksforme
Status: newclosed

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.

comment:4 Changed 18 months ago by 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 :)

comment:5 Changed 18 months ago by 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.

comment:6 Changed 18 months ago by 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

comment:7 Changed 18 months ago by 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;

comment:8 Changed 18 months ago by 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...

Edit: all this makes me wonder if I somehow messed up the updating... Any thoughts on how to get this correct again?

Last edited 18 months ago by postgispaul (previous) (diff)

comment:9 Changed 18 months ago by 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.

comment:10 Changed 18 months ago by 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

Note: See TracTickets for help on using tickets.