Change History (8)
comment:1 by , 16 years ago
| Milestone: | postgis 1.4.0 → postgis 2.0.0 |
|---|
comment:2 by , 16 years ago
Regarding Mark's thought of YES WE CAN if we fiddle with the system catalogs and my thought of YES WE CAN (I think I might have gotten this idea from Kevin) — if we include a plpgsql function in there that checks to see what kind of mess we are dealing with before we fiddle around with people's functions and does the conditional right thing.
YES WE CAN do this without requiring a hard upgrade —- BUT — WE ARE VERY LATE on 1.4 and any YES WE CAN — I consider scope creep. I'm perfectly fine with putting this off to 1.5 (HINT HINT) and even throwing in Paul's "its almost Geodetic will satisfy 70% of people who need it" that we would be ashamed to call true geodetic.
comment:3 by , 16 years ago
Just because the types and operators are bound to the st_ signatures, it doesn't mean we can't do the remainder of the work, no?
But whatever happens, we *WANT* people to upgrade from 1.3 to 1.4 so whatever we have in place, we need to make sure that it works.
ATB,
Mark.
comment:4 by , 16 years ago
I'm tempted to say don't risk it so late in the game. I really would like to test this out more before we do this (who knows maybe we'll change our minds on the names again) and I'm just not going to have time if we hope to get 1.4 out before the end of JUNE. Which would be REALLY NICE.
comment:5 by , 15 years ago
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
Committed to trunk at r4750, watch out, function signature changes!
comment:6 by , 15 years ago
| Resolution: | fixed |
|---|---|
| Status: | closed → reopened |
Paul — hmm don't know what to say, except I'm really concerned about people upgrading. This essentially requires a dump reload of the database. I don't consider this done since you have not addressed the upgrade process.
If you remove all those functions, then that means people upgrading from say 1.3 to 1.4 (will be binding to their old versions) without them knowing it. This is an unfortunate side affect of our new approach to allow ooexistence of functions.
With that said — the upgrade has to be able to drop the one not use and rename the function in use and then replace.
So in short — unless you've given great thought into this (HINT HINT my proposed in #202 )
I don't think you can do this in 1.5. As we have stated minor versions do not require a dump reload though major versions can.
comment:7 by , 15 years ago
| Resolution: | → fixed |
|---|---|
| Status: | reopened → closed |
Sorry, this ticket is closed, I'm happy to work on a fresh one on upgrade issues for 1.5. These things get way too long and off-topic.
comment:8 by , 15 years ago
Paul, I take it you have your heart set on doing this in 1.5. Okay I won't get in your way. But PLEASE make the upgrade painless (yes put in another ticket for upgrade). And if you can't I'll be really disappointed since its going to be harder to get people to upgrade to 1.5 (especially those with huge databases that take hours to restore) if they need to do a dump restore. I think that's pretty important to stress test the geography type before we add more to it.
Because types and operators were (sadly) bound to the st_ signatures during the changeover, it's not possible to remove them without making soft upgrade impossible. Deferring to 2.0.