Обсуждение: pg_dump data structures for triggers

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

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-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?

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-10e1b@webprd-a87.mail.aol.com
-- 
Vik Fearing                                          +33 6 46 75 15 36
http://2ndQuadrant.fr     PostgreSQL : Expertise, Formation et Support

Vik Fearing <vik@2ndquadrant.fr> writes:
> 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-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.

> 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-10e1b@webprd-a87.mail.aol.com

That sounds like a new feature, and not something we'd want to backpatch.
        regards, tom lane