Peter Eisentraut <pete...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
