Re: Suggested "easy" TODO: pg_dump --from-list
От | Tom Lane |
---|---|
Тема | Re: Suggested "easy" TODO: pg_dump --from-list |
Дата | |
Msg-id | 19588.1290614714@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Suggested "easy" TODO: pg_dump --from-list (Joachim Wieland <joe@mcknight.de>) |
Список | pgsql-hackers |
Joachim Wieland <joe@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
В списке pgsql-hackers по дате отправления: