Teodor Sigaev <teodor@sigaev.ru> writes:
>> That still puts the responsibility on the individual datatype author to
>> get it right. The case I'm most worried about is user-written datatypes
>> that are never going to magically acquire such asserts.
> It seems to me that working with two assumption (binary equal and
> catalog-defined equal function) in the same time is a wrong way. If we decide to
> use binary equal criteria, then why we need catalog-defined equal at all? If we
> use catalog-defined one, why we should require binary equality? Using both way
> in the same time is an error prone. It's possible to say that two value is equal
> if they are binary the same, if not - we should find catalog-defined equal
> operation and call it. Binary comparison is only an optimization.
That only works if there is a unique function that we can say is "THE"
equal operation for the datatype (with a true result guaranteeing that
every operation the datatype has will produce the same results from the
two values). There is no such concept in PG at the moment, and if
memory serves there are at least three built-in types for which the
default btree "equality" function in fact doesn't guarantee that.
So even if we wanted to pursue that path, it wouldn't produce a fix
that we could back-patch.
regards, tom lane
