Robert Haas wrote:
On Thu, Jun 10, 2010 at 9:35 AM, Stefan Kaltenbrunner
<ste...@kaltenbrunner.cc> wrote:
I do agree that the human readability of pg_dump is an asset in many
situations - I have often dumped out the DDL for particular objects
just to look at it, for example. However, I emphatically do NOT agree
that leaving someone with a 500MB dump file (or, for some people on
this list, a whole heck of a lot larger than that) that has to be
manually edited to reload is a useful behavior. It's a huge pain in
the neck.
well that's why we recommend to use the new version of pg_dump to dump the
old cluster if the intention is an upgrade not sure that is any more pain
than manually hacking the dump...
Maybe so, but I don't give either method high marks for convenience.
Suppose I have a server running 8.2 and I'm going to wipe it and
install the latest version of $DISTRIBUTION which bundles 8.4. What
our current policy essentially means is that I have to get 8.4 running
on the old server before I wipe it (presumably compiling by hand,
since the old version of the distro doesn't ship it), or else manually
frobnicate the dump after I wipe it, or else find another server
someplace to install 8.4 on and run the dump there prior to the OS
upgrade. This really sucks. It's a huge pain in the tail, especially
for people who aren't used to compiling PG from source at the drop of
a hat.
that's actually a limitation of the distribution packaging. Debian (and
ubuntu) have solved that issue already and I believe Devrim is working
on fixing that for the rpms as well.
I'm sure someone will tell me my system administration practices suck,
but people do these kinds of things, in real life, all the time.
Maybe if we all had an IQ of 170 and an infinite hardware budget we
wouldn't, but my IQ is only 169. :-)
ESXi is free, so is xen, kvm, virtualbox and whatnot :)
Stefan
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
