Re: Further cleanup of pg_dump/pg_restore item selection code

"David G. Johnston" writes: > Should pg_restore fail if asked to --create without a database entry in the > TOC? Yeah, I wondered about that too. This patch makes it a non-issue for archives created with v11 or later pg_dump, but there's still a hazard if you're

Re: Further cleanup of pg_dump/pg_restore item selection code

On Wednesday, January 24, 2018, Tom Lane wrote: > > 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. > I missed the implication though I read and even thought

Re: Further cleanup of pg_dump/pg_restore item selection code

On Wednesday, January 24, 2018, Tom Lane wrote: > > > This does not go all the way towards making pg_restore's item selection > switches dump subsidiary objects the same as pg_dump would, because > pg_restore doesn't really have enough info to deal with indexes and > table

Re: Further cleanup of pg_dump/pg_restore item selection code

"David G. Johnston" writes: > On Wednesday, January 24, 2018, Tom Lane 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

Further cleanup of pg_dump/pg_restore item selection code

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