Hi Kevin,
On 2013-09-12 15:27:27 -0700, Kevin Grittner wrote:
> The new operator is logically similar to IS NOT DISTINCT FROM for a
> record, although its implementation is very different. For one
> thing, it doesn't replace the operation with column level operators
> in the parser. For another thing, it doesn't look up operators for
> each type, so the "identical" operator does not need to be
> implemented for each type to use it as shown above. It compares
> values byte-for-byte, after detoasting. The test for identical
> records can avoid the detoasting altogether for any values with
> different lengths, and it stops when it finds the first column with
> a difference.
In the general case, that operator sounds dangerous to me. We don't
guarantee that a Datum containing the same data always has the same
binary representation. E.g. array can have a null bitmap or may not have
one, depending on how they were created.
I am not actually sure whether that's a problem for your usecase, but I
get headaches when we try circumventing the type abstraction that way.
Yes, we do such tricks in other places already, but afaik in all those
places errorneously believing two Datums are distinct is not error, just
a missed optimization. Allowing a general operator with such a murky
definition to creep into something SQL exposed... Hm. Not sure.
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services
