> > 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 ...