On Mon, Feb 18, 2013 at 06:49:14AM -0800, Kevin Grittner wrote: > Alvaro Herrera <alvhe...@2ndquadrant.com> wrote: > > Maybe it would be a good idea to try to put such commands at the > > very end of the dump, if possible.
> 25, /* DO_POST_DATA_BOUNDARY */ > 26, /* DO_CONSTRAINT */ > 27, /* DO_INDEX */ > 28, /* DO_REFRESH_MATVIEW */ > 28 /* DO_MATVIEW_INDEX */ > 29, /* DO_RULE */ > 30, /* DO_TRIGGER */ > 31, /* DO_FK_CONSTRAINT */ > 32, /* DO_DEFAULT_ACL */ > 33, /* DO_EVENT_TRIGGER */ > > I don't think that pushing MV refreshes and index creation farther > down the list should require anything beyond adjusting the priority > numbers. I don't see a problem pushing them to the end. Does > anyone else see anything past priority 28 that MV population should > *not* follow? DO_EVENT_TRIGGER should remain last; it may change the behavior of nearly any other command. Moving DO_REFRESH_MATVIEW past DO_TRIGGER would affect the outcome when the MV calls functions that ultimately trip triggers or rules. Currently, the behavior will be the same as for CHECK constraints: the rules and triggers don't exist yet. This may also affect, for the better, MVs referencing views that need the CREATE TABLE ... CREATE RULE _RETURN restoration pathway. It looks like a positive change. On the flip side, I wonder if there's some case I'm not considering where it's important to delay restoring rules and/or triggers until after restoring objects for which restoration can entail calls to arbitrary user functions. -- Noah Misch EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
