> 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
