#189 closed enhancement (fixed)
Safe route for upgrading from 1.3.x to 1.4
| Reported by: | dylan | Owned by: | pramsey |
|---|---|---|---|
| Priority: | medium | Milestone: | PostGIS 1.4.0 |
| Component: | postgis | Version: | 1.4 |
| Keywords: | Cc: |
Description
Seems like there is no simple (safe) upgrade path to go from postgis 1.3.x to postgis 1.4— apart from a dump/restore operation.
Change History (5)
comment:1 by , 15 years ago
| Milestone: | → postgis 1.4.0 |
|---|---|
| Version: | → 1.4 |
comment:2 by , 15 years ago
| Milestone: | postgis 1.4.0 → postgis 1.4.1 |
|---|---|
| Type: | defect → enhancement |
comment:3 by , 15 years ago
Okay this is what I was looking for — loks like the special DROP AGGREGATE IF EXISTS was introduced in 8.2 (not 8.3 as I had thought). We are not supporting 8.1 for 1.4 correct. This IF EXISTS part of the clause was introduced in 8.2 — so I think we can change our scripts to use this. People like me who have views that reference aggs will still have to deal with things manually though since i don't think we ever want to do a CASCADE). So the only other issue is that did disk storage change between 1.3. and 1.4?
http://www.postgresql.org/docs/8.2/static/sql-dropaggregate.html
comment:4 by , 15 years ago
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
This is good, thanks robe. I have committed to trunk at r4132.
comment:5 by , 15 years ago
| Milestone: | postgis 1.4.1 → postgis 1.4.0 |
|---|
Paul — I pushed this to 1.4.1. To me this is not a bug but an enhancement. Its fairly well-defined that you need to do a dump restore when going from semi-major to semi-major. No reason to hold 1.4 up for this. Though its a good feature to have period and actually one that came up in PGCon2009 not in terms of PostGIS but overall PostgreSQL upgrades.
With Bruce Momjian pgmigrator in beta that does an in place upgrade from 8.3 to 8.4 he mentioned PostGIS and TSearch aas a concern. I think we should be safe as far as PostGIS goes with that (same version) but haven't tested his thing out yet.
I guess as long as there are no disk changes between 1.3 and 1.4 (I think Stephen Frost asked and I was not 100% sure if there was or wasn't). Then this might simply be an overall non-version documentation issue and should not be holding up any release.
We really need to nail down our policy of what changes users can expect from version to version 1) we only make disk changes in major releases, 2) function adds in or or lib path changes in semi-major 3) function enhancements that introduce no new functional signatures in semi-minor
I think it would vary a bit from person to person — e.g. the main issue is with aggregates and path changes — but to fully fix that we need to be able to drop the aggregates, but can't if they are in use in views which in my case they often are. 8.3 and 8.4 I believe have a relace agg or IF agg exists or something like that that makes upgrade a bit easier in those.