Re: pg_restore dbname
От | Tom Lane |
---|---|
Тема | Re: pg_restore dbname |
Дата | |
Msg-id | 21201.1588185315@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | pg_restore dbname (PG Doc comments form <noreply@postgresql.org>) |
Список | pgsql-docs |
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
В списке pgsql-docs по дате отправления: