"David G. Johnston" <david.g.johns...@gmail.com> writes: > On Wednesday, January 24, 2018, Tom Lane <t...@sss.pgh.pa.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