On Mon, Sep 16, 2013 at 04:28:23PM +0200, Andres Freund wrote:
> On 2013-09-15 19:49:26 -0400, Noah Misch wrote:
> > Type-specific identity operators seem like overkill, anyway. If we find that
> > meaningless variations in a particular data type are causing too many false
> > non-matches for the generic identity operator, the answer is to make the
> > functions generating datums of that type settle on a canonical form. That
> > would be the solution for your example involving array null bitmaps.
>
> I think that's pretty much unrealistic. I am pretty sure that if either
> of us starts looking we will find at about a dozen of such cases and
> miss the other dozen. Not to speak about external code which is damn
> likely to contain such cases.
It wouldn't be a problem if we missed cases or declined to update known cases.
The array example probably isn't worth changing. Who's going to repeatedly
flip-flop an array column value between the two representations and then
bemoan the resulting MV write traffic?
> And I think that efficiency will often make such normalization expensive
> (consider postgis where Datums afaik can exist with an internal bounding
> box or without).
If it's so difficult to canonicalize between two supposedly-identical
variations, it's likewise a stretch to trust that all credible operations will
fail to distinguish between those variations.
> I think it's far more realistic to implement an identity operator that
> will fall back to a type specific operator iff equals has "strange"
> properties.
Complicating such efforts, the author of a custom identity operator doesn't
have the last word on functions that process the data type. Take your postgis
example; if a second party adds a has_internal_bounding_box() function, an
identity operator ignoring that facet is no longer valid.
memcmp() has served well for HOT and for _equalConst(); why would it suddenly
fall short for MV maintenance?
nm
--
Noah Misch
EnterpriseDB http://www.enterprisedb.com