On Mon, 2003-09-15 at 13:24, Joshua D. Drake wrote:
> > Strawmen. If we provide a good upgrade capability, we would just
> > simply have to think about upgrades before changing features like
> > that. The upgrade code could be cognizant of these sorts of things;
> > and shoud be, in fact.
>
> Sure but IMHO it would be more important to fix bugs like the parser not
> correctly using indexes on bigint unless the value is quoted...
>
> I think everyone would agree that not having to use initdb would be nice
> but I think there is much more important things to focus on.
>
> Besides if you are upgrading PostgreSQL in a production environment I
> would assume there would be an extremely valid reason. If the reason is
> big enough to do a major version upgrade then an initdb shouldn't be all
> that bad of a requirement.
Hmmm. A (US-oriented) hypothetical:
BOSS: The app works now. Why rock the boat?
DBA: The new version has features that will save 20% disk space,
and speed up certain operations by 75% every day.
BOSS: Fantastic! How long will it take to upgrade?
DBA: 18 hours.
BOSS: 18 hours!! We can only take that much downtime on Thanks-
giving weekend, or 3-day July 4th, Christmas or New Year's
weekends.
--
-----------------------------------------------------------------
Ron Johnson, Jr. ron.l.johnson@cox.net
Jefferson, LA USA
"(Women are) like compilers. They take simple statements and
make them into big productions."
Pitr Dubovitch
