I'm looking into fixing the problem reported here:
http://www.postgresql.org/message-id/1445A624-D09F-4B51-9C41-46BA1E2D6862@neveragain.de
namely that if we split a view into a table + rule (because of circular
dependencies), parallel pg_restore fails to ensure that it creates any
triggers for the view only after creating the rule. If it tries to
create the triggers first, the backend may barf because they're the wrong
type of triggers for a plain table.
While it's not that hard to make pg_dump add some more dependencies while
breaking a circular dependency, there's a small problem of finding the
view's triggers so we can attach those dependencies to them. AFAICS, with
the current pg_dump data structures, there is actually no better way to
do that than to iterate through every DumpableObject known to pg_dump to
see which of them are TriggerInfos pointing to the view relation :-(.
What I have in mind is to add linked-list fields to TableInfo and
TriggerInfo to allow all the triggers of a table to be found by chasing
a list. The increment in the size of those data structures isn't much,
and we may have other uses for such an ability later.
Anybody have an objection or better idea?
regards, tom lane