On Wednesday, January 24, 2018, Tom Lane <
tgl@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.
