On Fri, Jan 19, 2018 at 10:00 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Fri, Jan 19, 2018 at 9:45 AM, Tom Lane <tgl@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