From: Tom Lane <tgl@sss.pgh.pa.us>
To: scorpy@gmail.com
cc: pgsql-docs@lists.postgresql.org
Subject: Re: pg_restore dbname
In-reply-to: <158817493335.671.15980961934499341141@wrigleys.postgresql.org>
References: <158817493335.671.15980961934499341141@wrigleys.postgresql.org>
Comments: In-reply-to PG Doc comments form <noreply@postgresql.org>
	message dated "Wed, 29 Apr 2020 15:42:13 -0000"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <21200.1588185315.1@sss.pgh.pa.us>
Date: Wed, 29 Apr 2020 14:35:15 -0400
Message-ID: <21201.1588185315@sss.pgh.pa.us>
Precedence: bulk

PG Doc comments form <noreply@postgresql.org> writes:
> "-C
> --create
> ...
>     When this option is used, the database named with -d is used only to
> issue the initial DROP DATABASE and CREATE DATABASE commands. All data is
> restored into the database name that appears in the archive."

> I am finding the opposite happening from that final sentence. When I use
> --clean and --create, it is using the database name from the archive during
> the DROP and CREATE commands, and using the --dbname argument for the actual
> data restore.

Well, it'll initially connect to the database named in -d, issue DROP and
CREATE DATABASE commands naming the target database from there, and then
reconnect to the newly-created database to restore its contents.  If you
can show that it's not doing that, that'd be grounds for a bug report
(with some backing details).

> However, do either things make sense? Shouldn't all of these
> commands be executed against the provided database name in the command?

No, because dropping the database one is currently connected to is
disallowed.  So --clean/--create *can't* work that way.

> How
> can I take a backup from my production environment and restore it into my
> test environment, if the db names are different?

Don't use --create.  Just give the existing target DB name in -d.
(You can use --clean if you want, but it's probably better to
drop and recreate the test DB manually.)

BTW, the behavior in this area changed a bit in v11, so be careful
you are reading docs that correspond to the pg_restore version
you are using.  I don't think this specific thing changed, but
the overall division of labor between pg_dump and pg_dumpall
changed.

			regards, tom lane