2012/11/27 Dimitri Fontaine <dimi...@2ndquadrant.fr>: > 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). :) >
+1 Pavel > 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
