"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 restoring from an archive made by
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 about questioning
tha
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 constraints the way pg_d
"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 pg_restore do not
>> suggest that --create might fail i
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 used, because tables
As I've been hacking on the pg_dump code recently, I got annoyed at the
ugliness of its code for deciding whether or not to emit database-related
TOC entries. That logic is implemented in a completely different place
from other TOC entry selection decisions, and it has a bunch of strange
behaviors
