Re: Further cleanup of pg_dump/pg_restore item selection code

"David G. Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> writes:
> On Wednesday, January 24, 2018, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> The same behaviors occur if you do e.g.
>> pg_dump -Fc -t sometable somedb | pg_restore --create
>> which is another undocumented misbehavior: the docs for pg_restore do not
>> suggest that --create might fail if the source archive was selective.

> pg_restore -t:

> "When -t is specified, pg_restore makes no attempt to restore any other
> database objects that the selected table(s) might depend upon. Therefore,
> there is no guarantee that a specific-table restore into a clean database
> will succeed."

I think you might be missing one of the main points here, which is
that --create is specified as causing both a CREATE DATABASE and a
reconnect to that database. If it silently becomes a no-op, which
is what happens today, the restore is likely to go into the wrong
database entirely (or at least not the DB the user expected).

I won't deny the possibility that some people are depending on the
existing wrong behavior, but that's a hazard with any bug fix.

regards, tom lane