On 02/04/2016 01:44 AM, Tom Lane wrote: > I'm looking into fixing the problem reported here: > http://www.postgresql.org/message-id/1445a624-d09f-4b51-9c41-46ba1e2d6...@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?
No objections to this, but my "better idea" is simply to allow INSTEAD OF triggers on tables like discussed last year. http://www.postgresql.org/message-id/14c6fe168a9-1012-10...@webprd-a87.mail.aol.com -- Vik Fearing +33 6 46 75 15 36 http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers