Stephen Frost <sfr...@snowman.net> wrote: > If we were consistently copying and updating the value based on > some external knowledge that the value has changed (similar to > how slony works w/ triggers that dump change sets into a table- > it doesn't consider "has any value on this row changed?"; the > user did an update, presumably for some purpose, therefore the > change gets recorded and propagated), I'd be perfectly happy.
That is the equivalent of the incremental maintenance feature which won't be coming until after REFRESH has settled down. REFRESH is more like the slony initial population of a table. REFRESH CONCURRENTLY is a way of doing that which allows users to continue to read from the matview without blocking or interruption while the REFRESH is running; I think it would be a bug if that could generate different results from a non-CONCURRENT REFRESH. Wanting incremental maintenance (which we all want) is no reason to block an earlier implementation of REFRESH CONCURRENTLY which is not, and does not use, incremental maintenance. -- Kevin Grittner EDB: 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
