Stephen Frost <sfrost@snowman.net> wrote:
>> I think the conservative (and therefore correct) approach is to
>> decide that we're always going to update if we detect any
>> difference at all.
>
> And there may be users who are surprised that a refresh changed
> parts of the table that have nothing to do with what was changed
> in the underlying relation, because a different plan was used and
> the result ended up being binary-different.
Binary different for "equal" values could include box (or other
geometry) objects moved to completely new locations and/or not
quite the same size.
Here is v2 of the patch which changes from the universally disliked
operator names v1 used. It also fixes bugs in the row comparisons
for pass-by-reference types, fixes a couple nearby comments, and
adds regression tests for a matview containing a box column.
The box type is interesting in that its = operator only worries
about the area of the box, and considers two boxes with no more
than EPSILON difference to be equal. This means that boxes at
totally different locations can be equal, and that if A = B and B =
C it is not necessarily true that A = C. This doesn't cause too
much trouble in general because boxes don't have btree opclasses.
Since there are types, including core types, without a default
btree opclass, materialized views containing them cannot use RMVC
as currently committed. This patch would fix that, or we could rip
out the current implementation and go to the "delete everything and
insert the entire new matview contents" approach.
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company