> > And that has nothing to do with user need as a whole, since the care > > level I mentioned is predicated by the developer interest level. > > While I know, Marc, how the whole project got started (I have read the > > first posts), and I appreciate that you, Bruce, Thomas, and Vadim > > started the original core team because you were and are users of > > PostgreSQL, I sincerely believe that in this instance you are out of > > touch with this need of many of today's userbase.
Huh? I have no disagreement that upgrading is a key feature that we are lacking ... but, if there are any *on disk* changes between releases, how do you propose 'in place upgrades'? Granted, if its just changes to the system catalogs and such, pg_upgrade should be able to be taught to handle it .. I haven't seen anyone step up to do so, and for someone spending so much time pushing for an upgrade path, I haven't seen you pony up the time ... Just curious here ... but, with all the time you've spent pushing for an "easy upgrade path", have you looked at the other RDBMSs and how they deal with upgrades? I think its going to be a sort of apples-to-oranges thing, since I imagine that most of the 'big ones' don't change their disk formats anymore ... What I'd be curious about is how badly we compare as far as major releases are concerned ... I don't believe we've had a x.y.z release yet that required a dump/reload (and if so, it was a very very special circumstance), but what about x.y releases? In Oracle's case, i don't think they do x.y.z releases, do they? Only X and x.y? K, looking back through that it almost sounds like a ramble ... hopefully you understand what I'm asking ... I know when I was at the University, and they dealt with Oracle upgrades, the guys plan'd for a weekend ... ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster