Re: Materialized views WIP patch

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