Re: pg_dump design problem (bug??)

On Tuesday 27 June 2006 11:10, Karl O. Pinc wrote:
> 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.)
>

I think I would prefer the former... pg_dumpall --database foo that dumped
all globals along with a specific database.

> 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.
>

Probably more of no one getting around to it, but you need to come up with a
solution that doesnt break backwards compatability; ie you need to be able to
still make "dbname" agnostic dumps with pg_dump.

--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL