From: | teg(at)redhat(dot)com (Trond Eivind =?iso-8859-1?q?Glomsr=F8d?=) |
---|---|
To: | Brook Milligan <brook(at)biology(dot)nmsu(dot)edu> |
Cc: | lamar(dot)owen(at)wgcr(dot)org, tgl(at)sss(dot)pgh(dot)pa(dot)us, scrappy(at)hub(dot)org, pgsql-general(at)postgresql(dot)org |
Subject: | Re: 7.1 Release Date |
Date: | 2000-08-29 19:19:25 |
Message-ID: | xuy66ojx4ci.fsf@hoser.devel.redhat.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Brook Milligan <brook(at)biology(dot)nmsu(dot)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.
From | Date | Subject | |
---|---|---|---|
Next Message | Adam Lang | 2000-08-29 19:22:14 | Re: foreign keys - script |
Previous Message | Stephan Szabo | 2000-08-29 19:17:54 | Re: foreign keys - script |