Opened 12 months ago
Closed 12 months ago
#5623 closed defect (fixed)
unpackaged upgrade from PostGIS 3.2 failing on ST_AsGeoJSON
Reported by: | robe | Owned by: | strk |
---|---|---|---|
Priority: | blocker | Milestone: | PostGIS 3.5.0 |
Component: | upgrade/hard | Version: | master |
Keywords: | Cc: |
Description
As a result of #5596 we are getting this regression on woodie. I can't replicate it locally, perhaps cause I am running PG16 and only have 3.3 and 3.4 installed or because I can't get the unpackaged path to kick in.
ALTER TABLE ALTER TABLE SELECT 8500 DELETE 8500 SET SET SET SET SET set_config ------------ (1 row) SET SET SET SET ERROR: function "st_asgeojson" already exists with same argument types ----------------------------------------------------------------------------- make: *** [/woodpecker/src/git.osgeo.org/gitea/postgis/postgis/regress/runtest.mk:24: check-regress] Error 3 make: Leaving directory '/woodpecker/src/git.osgeo.org/gitea/postgis/postgis/build/pg15/regress' FAIL: postgis script hard upgrade unpackaged3.2--:auto Cleaning up
This doesn't seem to affect extension upgrades.
I see the new signature in postgis_restore_data.generated
Does the old signature need to be put somewhere besides the postgis_drop_before.sql?
Change History (5)
comment:1 by , 12 months ago
comment:2 by , 12 months ago
I could reproduce, locally, with:
regress/run_test.pl -v --dumprestore --upgrade-path unpackaged3.2--:auto regress/core/regress ERROR: function "st_asgeojson" already exists with same argument types
The upgrade script is clearly not finding a match for the identity passed to _postgis_drop_function_by_identity
comment:3 by , 12 months ago
To be noted that soft-upgrade works, so this is related to the postgis_restore.pl script failing to recognize the identity of the function in the dump
comment:4 by , 12 months ago
I confirm using Replaces fixes this problem. This is because Replaces will use signature, not identity, and we only care about signatures (not identities) for the skip-list of postgis_restore.pl
I think it should be ok to use _postgis_drop_function_by_identity in postgis_drop_before as you did, although I wonder why you didn't use a Replaces tag instead, which would have been quicker to type.
I'll see to reproduce locally to fix it