From: | "Karl O(dot) Pinc" <kop(at)meme(dot)com> |
---|---|
To: | nikolay(at)samokhvalov(dot)com |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: pg_dump design problem (bug??) |
Date: | 2006-06-27 15:10:20 |
Message-ID: | 1151421020l.27161l.3l@mofo |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On 06/27/2006 09:29:36 AM, Nikolay Samokhvalov wrote:
> So, what about it?
>
> I periodically encounter with the same problem. People (e.g. me :-)
> but not only) expect that when they use pg_dump to backup some
> database (either schema only or both schema and data), all database
> properties will be dumped and, then, restored.
>
> People think that this thing seems to be gotcha. Anyway, if we can
> assign variable's value to database, it makes this value to be the
> property of database and, therefore, should be dumped...
There are obvious acceptable work-arounds, but none (AFIK) that don't
involve having to manually look through a bunch of pg_dumpall output
if you want to restore just one database. There are only 2 real
choices, either pg_dumpall takes an option to specify just one
db be dumped, or pg_dump takes a flag that allows "alter database"
into the output and pg_restore takes a flag that ignores
such "alter database" information. I'd prefer
pg_dump/pg_restore, it has the advantage
of producing a single file per db. (Humm, it'd probably
be best if the pg_restore flag only worked on
-F c style data.)
The real question is whether the pg developers would
object to such a feature, whatever the design is,
or whether it's just that nobody's
gotten around to writing it.
Karl <kop(at)meme(dot)com>
Free Software: "You don't pay back, you pay forward."
-- Robert A. Heinlein
From | Date | Subject | |
---|---|---|---|
Next Message | Hannes Dorbath | 2006-06-27 15:17:30 | Re: TSearch vs. Homebrew |
Previous Message | Nikolay Samokhvalov | 2006-06-27 14:29:36 | Re: pg_dump design problem (bug??) |