On Mon, Feb 18, 2013 at 06:49:14AM -0800, Kevin Grittner wrote:
> Alvaro Herrera <alvherre@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
