Joseph Tate <jtate@dragonNOSPAMstrider.com> writes:
> pg_restore: connecting to database for restore
> pg_restore: dropping RULE au_d_assigned_template
> pg_restore: dropping RULE au_u_assigned_template
> ... More rules, triggers, constraints, indexes and functions removed
> pg_restore: dropping ACL au_assigned_template
> pg_restore: dropping TABLE au_assigned_template
> pg_restore: NOTICE: rule au_d_assigned_template on table
> assigned_template depends on table au_assigned_template
> pg_restore: NOTICE: rule au_u_assigned_template on table
> assigned_template depends on table au_assigned_template
> pg_restore: [archiver (db)] could not execute query: ERROR: Cannot drop
> table au_assigned_template because other objects depend on it
> Use DROP ... CASCADE to drop the dependent objects too
> pg_restore: *** aborted because of error
> I find it odd that it refuses to drop table au_assigned_template because
> the two rules depend on it when the rules have already been dropped.
Are you sure those aren't rules on some other table that chance to have
the same names as the problematic rules?
Until very recently (CVS tip of a couple days ago) pg_dump did not
really have the smarts to ensure that it always did things in a "safe"
order that wouldn't fall foul of inter-object dependencies. I suspect
what you have here is just an example of that.
regards, tom lane