Re: pg_restore error: function plpgsql_call_handler already exists with same argument types
От | Nick Fankhauser |
---|---|
Тема | Re: pg_restore error: function plpgsql_call_handler already exists with same argument types |
Дата | |
Msg-id | NEBBLAAHGLEEPCGOBHDGCEHJGEAA.nickf@ontko.com обсуждение исходный текст |
Ответ на | Re: pg_restore error: function plpgsql_call_handler already exists with same argument types (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: pg_restore error: function plpgsql_call_handler already exists with same argument types
|
Список | pgsql-admin |
> You could check this by running pg_restore with query logging > turned on, to see what commands it's actually issuing -- or just do > "pg_restore -s" into a text file and eyeball the generated script. I did this, and there is a view created before the table it refers to. > There are a lot of situations where pg_dump fails to pick a safe reload > order at the moment (that's why pg_restore has that wild and woolly set > of options for manual adjustment of the reload order). So... it looks like my best option at this point is to use the -l switch to create an archive list, reorder the list as needed, and then invoke pg_restore with the -L switch. The DB is pretty stable, so this wouldn't be too painful, but it seems like given this limitation, a person with room to spare might want to do both an older style test dump of the whole DB and an archive format dump to cover both wholesale and piecemeal recovery scenarios in a convenient way. Is this considered a bug, or a generally accepted limitation? -NF
В списке pgsql-admin по дате отправления: