On Fri, Jan 19, 2018 at 10:00 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> On Fri, Jan 19, 2018 at 9:45 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: >>> Well, we could say that the properties of template1 and postgres >>> are only restored if you use --clean. > >> True. Would that be a POLA violation, do you think? > > It seems a bit non-orthogonal. Also, while your point that people > expect "merge" behavior from pg_dump is certainly true, I'm not > convinced that anybody would be relying on that for pg_dumpall.
What I expect typically happens is that someone restores into an existing cluster and then realizes their mistake and goes and removes all of the extra stuff that got created. This is a bit like when you run tar -zxf expecting it to create a subdirectory, but it turns out to extract in the current directory instead. You then curse your fate and remove all of the files it created. It's annoying, but not that bad. If it nuked the contents of the currently directory first, though, you'd be much sadder. If somebody changed tar to have that behavior, people would probably *eventually* become aware of the risk and adjust their behavior to avoid catastrophe, but it would probably take 1-2 disasters per individual before they got used to the new way, and that's a lot of disasters considering how many people use tar. Or, maybe people wouldn't get used to it and they'd just go after whoever made the change with pitchforks. Anyway, that kind of thing seems like a danger here. The other possibility that comes to mind is that somebody might be doing this is working around a failure of something like CREATE LANGUAGE. Say the name of the .so has changed, so CREATE LANGUAGE will fail or do the wrong thing. Instead of editing the dump, they pre-install the language with the correct definition and then restore over it, ignoring errors. I guess that would only work with pg_dump, not pg_dumpall, unless the database that had the problem was one of the pre-created ones. Still, it's worth thinking over these kinds of scenarios, I think. People do a lot of ugly things in the real world that we as developers would never do, mostly to work around the problems we fail to foresee. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company