Re: 7.1 Release Date - Mailing list pgsql-general

From teg@redhat.com (Trond Eivind Glomsrød)
Subject Re: 7.1 Release Date
Date
Msg-id xuy66ojx4ci.fsf@hoser.devel.redhat.com
Whole thread Raw
In response to Re: 7.1 Release Date  (The Hermit Hacker <scrappy@hub.org>)
List pgsql-general
Brook Milligan <brook@biology.nmsu.edu> writes:

> YOU (i.e., people relying on the RH stuff to do everything at once)
> may need such a thing, but it seems like you are overstating the case
> just a bit.  If this project gets adopted by core developers, it would
> seem to conflict drastically with the goal of developing the core
> functionality.

Upgradability is also functionality.

> There is nothing inherently different (other than implementation
> details) about the basic procedure for upgrading the database as
> compared to upgrading user data of any sort.  In each case, you need
> to go through the steps of 1) dump data to a secure place, 2) destroy
> the old stuff, 3) add new stuff, and 4) restore the old data.  In the
> case of "normal" user data (home directories and such) the
> dump/restore sequence can be performed using exactly those commands or
> tar or dd or whatever.

You usually don't do that at all - the home directories and the users'
data stay just the way they are.
>
>

--
Trond Eivind Glomsrød
Red Hat, Inc.

pgsql-general by date:

Previous
From: teg@redhat.com (Trond Eivind Glomsrød)
Date:
Subject: Re: 7.1 Release Date
Next
From: Stephan Szabo
Date:
Subject: Re: foreign keys - script