#2510 closed defect (fixed)
Remove postgis_major_version_check from postgis_upgrade_20_21.sql
Reported by: | pramsey | Owned by: | pramsey |
---|---|---|---|
Priority: | critical | Milestone: | PostGIS 2.1.1 |
Component: | postgis | Version: | 2.1.x |
Keywords: | Cc: |
Description
Actually, it's added by the utils/postgis_proc_upgrade.pl script, that autogenerates the upgrade script from the uninstall/install script. The upgrade script is then copied into the EXTENSIONS area and reused for extension scripts too. This should also apply to trunk/2.2
As it stands, the postgis_major_version_check is prevently successful use of the "alter extension upgrade" path for packaged postgis installations, that do not have both versions installed simultaneously (presumably our testing didn't find this because developers frequently/always have a lot of versions simultaneously installed)
Change History (9)
comment:1 by , 11 years ago
comment:2 by , 11 years ago
This function ends up in a file named postgis_upgrade_20_21.sql.
Weigh the "maybe some idiot might do this sometime" nicety against the fact that *right now* people are unable to do packaged updates of postgis. Removing this and getting an upgradeable 2.1 packaged seems pretty important, to me. Also, this function does nothing for anything except "is this script being applied against a verison 1.x instance", so it would do nothing for the case you mention. Let's get rid of it and do a 2.1 minor release.
comment:3 by , 11 years ago
+1 for let's get rid of it. It causes more problems than it solves since most distros uninstall the old version, making this function damaging for upgrade.
comment:6 by , 11 years ago
The revision above keeps trying with postgis_lib_version() but catches an exception by reverting to use of postgis_script_version(). If you like the resulting experience it'll have to be backported to 2.1 and 2.0 branches.
comment:7 by , 11 years ago
That works for me in a test on OSX.
- build/install 2.0
- create database and postgis extension
- uninstall all 2.0 pieces (lib, contrib, extension)
- build/install 2.1
- alter postgis upgrade to 2.1
says to me should also fix our linux package upgraders
comment:8 by , 11 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
Committed to 2.1 branch at r12055
The idea is to avoid misuse of upgrade scripts. The function could maybe be updated to only query for the sql-implemented version of the function, or to react to exceptions. But I think it is nice to have some safety net. If extensions do this by themselves then fine, but not I think it's less safe with extensions: try
CREATE EXTENSION POSTGIS VERSION '2.1.0' FROM unpackaged
while having 2.0.0 installed and I think you end up with a mess.