Peter Eisentraut <peter_e@gmx.net> writes:
> I'm not fond of overloading LOAD as the refresh command. Maybe you
> could go the Oracle route here as well and use a stored procedure. That
> would also allow things like SELECT pg_refresh_mv(oid) FROM ... more
> easily.
I would like that we have a way to refresh a Materialized View by
calling a stored procedure, but I don't think it should be the main UI.
The wholesale refreshing of a matview appears to me to be comparable to
TRUNCATE is that it's both a DDL and a DML. The incremental refreshing
modes we want to have later are clearly DML only, either on commit
refresh or incrementally on demand.
I would then propose that we use ALTER MATERIALIZED VIEW as the UI for
the wholesale on demand refreshing operation, and UPDATE MATERIALIZED
VIEW as the incremental command (to come later).
So my proposal for the current feature would be:
ALTER MATERIALIZED VIEW mv UPDATE [ CONCURRENTLY ]; UPDATE MATERIALIZED VIEW mv;
The choice of keywords and syntax here hopefully clearly hint the user
about the locking behavior of the commands, too. And as we said, the
bare minimum for this patch does *not* include the CONCURRENTLY option,
which we still all want to have (someday). :)
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
