Andres Freund <and...@2ndquadrant.com> wrote: > I assume that at some point matviews will get (auto-)updateable, > just as normal views recently got.
I'm dubious about that. Every use case I've seen for MVs involves aggregation, although they are a generalized feature, so that won't always be true. But if you have a view like: CREATE MATERIALIZED VIEW tm AS SELECT t.type, sum(t.amt) AS totamt FROM t GROUP BY t.type; ... I don't see how that can be updateable. If I add 5 to totamt for some row, what do you do? I expect that 99% of MVs will be updated asynchronously from changes to the underlying data -- what do you do if someone updates a row that no longer exists in the underlying data. This are just seems fraught with peril and out of sync with the usual uses of MVs. > What about DISABLE? DISCARD or DEALLOCATE would also be nice but > it seems hard to fit that into existing syntax. Thanks for the suggestions. -- Kevin Grittner EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
