Joachim Wieland <j...@mcknight.de> writes:
> Whatever approach we use, we need to think about the use case where 1%
> of the objects should be dumped but should also make sure that you can
> more or less easily dump 99% of the objects. Roberts use case is the
> 1% use case. Especially for the 99% case however, pg_dump needs to
> create a full list of all available objects in whatever format as a
> proposal so that you could just save & edit this list and then delete
> what you don't want instead of writing such a list from scratch.
For that I'd suggest an --exclude=pattern switch. I'm really not
happy with the idea of applying pg_restore's -l then -L workflow
to dumps from a live database. It's workable for pg_restore because
the dump file doesn't change underneath you between the two runs.
But having to make a list for pg_dump seems like a foot-gun. Imagine
a DBA who wants to exclude a large log table from his dumps, so he
makes a -l-like list and removes that table, sets up the cron job to
use that list, and forgets about it. Months later, he finds out that
his backups don't contain $critical-object-added-later. A static
external list of objects to be dumped just doesn't make sense to me.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
