On Wednesday, January 24, 2018, Tom Lane <t...@sss.pgh.pa.us> wrote: > and it has a bunch of strange > behaviors that can really only be characterized as bugs. An example is > that > > pg_dump --create -t sometable somedb > > pg_dump -t:
"The -n and -N switches have no effect when -t is used, because tables selected by -t will be dumped regardless of those switches, and non-table objects will not be dumped." a database is a non-table object...though the proposed behavior seems reasonable; but maybe worthy of being pointed out just like the -n switches are. (probably been asked before but why 'no effect' instead of 'will cause the dump to fail before it begins'?) > 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." That -t was specified on the dump instead of the restore could be clarified but applies nonetheless. Do we document anywhere what is a "database object" and what are "property objects" that are restored even when -t is specified? > Attached is a patch that proposes to clean this up. It arranges > things so that CREATE DATABASE (and, if --clean, DROP DATABASE) > is emitted if and only if you said --create, regardless of other > selectivity switches. Makes sense, the bit about regardless of other switches probably should find it's way into the docs. Adding a drop database where there never was one before is a bit disconcerting though...even if the switches imply the user should be expecting one, > > And it fixes selective pg_restore to include > subsidiary ACLs, comments, and security labels. +1 David J.
