Re: Building infrastructure for B-Tree deduplication that recognizeswhen opclass equality is also equivalence - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Building infrastructure for B-Tree deduplication that recognizeswhen opclass equality is also equivalence
Date
Msg-id CA+TgmoZB3oq7HuS+A-L5xxotLS6f7UZMOrNMHXnopDgyk2D=Og@mail.gmail.com
Whole thread Raw
In response to Re: Building infrastructure for B-Tree deduplication that recognizeswhen opclass equality is also equivalence  (Peter Geoghegan <pg@bowt.ie>)
Responses Re: Building infrastructure for B-Tree deduplication that recognizeswhen opclass equality is also equivalence  (Peter Geoghegan <pg@bowt.ie>)
List pgsql-hackers
On Mon, Dec 30, 2019 at 6:58 PM Peter Geoghegan <pg@bowt.ie> 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



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Removal of support for OpenSSL 0.9.8 and 1.0.0
Next
From: Stephen Frost
Date:
Subject: Re: TRUNCATE on foreign tables