Re: Building infrastructure for B-Tree deduplication that recognizes when opclass equality is also equivalence

On Mon, Dec 30, 2019 at 6:58 PM Peter Geoghegan <[email protected]> wrote:
> I propose that we adopt the following definition: For an operator
> class to be safe, its equality operator has to always agree with
> datum_image_eq() (i.e. two datums must be bitwise equal after
> detoasting).

I suggested using datumIsEqual() as the canonical definition. (I
wonder why datum_image_eq() does not reuse that function?)

> Note: In theory this definition is stricter than truly necessary to
> make deduplication safe, because we can imagine a contrived case in
> which an operator class exists where datum_image_eq() does not always
> agree with the equality operator, even though the equality operator
> will reliably consider two datums to be equal only when they have
> identical outputs from the underlying type's output function. This
> could happen when an operator class author wasn't very careful about
> zeroing padding -- this may not have mattered to the opclass author
> because nobody relied on that padding anyway. I think that stuff like
> this is not worth worrying about -- it can only happen because the
> datatype/operator class author was very sloppy.

+1.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company