On 09/18/2013 06:05 PM, Stephen Frost wrote:
> * Kevin Grittner (kgrittn@ymail.com) wrote:
>> Right. Not only would the per-type solution make materialized views
>> maintenance broken by default, requiring per-type work to make it
>> work reasonably, with silent failures for any type you didn't know
>> about, but "no user-visible differences" is a pretty slippery
>> concept.
> I don't like those possibilities, of course, but I'm starting to wonder
> about this whole concept of looking at it byte-wise. If I'm following
> correctly, what we're looking at here is having a way for matviews to
> tell if these bytes are the same as those bytes, for the purpose of
> deciding to update the matview, right?
Basically what is needed is to check if the rowm *might* have
changed, so the new value, which may or may not be "equal"
would be refreshed into matview.
> Yet we can then have cases where
> the row isn't *actually* different from a value perspective, yet we're
> going to update it anyway because it's represented slightly differently?
>
> What happens if we later want to add support for users to have a matview
> trigger that's called when a matview row *actually* changes? We'd end
> up calling it on what are essentially false positives, or having to do
> some double-check later on "well, did it *really* change?", neither of
> which is good at all. If we had the IS NOT DISTINCT FROM operators
> discussed, would that work for this even if it isn't as performant? Or
> is there an issue with that?
IS NOT DISTINCT solves the problem with weird equality of NULLS
and nothing else, so it would not help here.
What the proposed operator family solves is "possiby changed"
Cheers
--
Hannu Krosing
PostgreSQL Consultant
Performance, Scalability and High Availability
2ndQuadrant Nordic OÜ
