* 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? 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?
Thanks,
Stephen