Re: Hashable custom types

Paul Ramsey <pramsey(at)cleverelephant(dot)ca> writes:
>> UNION will preferentially glom onto the btree equality operator, if memory
>> serves. If that isn't also the hash equality operator, things won't work
>> pleasantly.

> So what does that mean for types that have both btree and hash equality operators? Dont all the built-ins also have this problem?

What I'm asking is why it would possibly be sensible to have different
notions of equality for hash and btree. In every existing type that has
both btree and hash opclasses, the equality members of those opclasses
are *the same operator*. You don't really want UNION giving different
answers depending on which implementation the planner happens to pick,
do you?

regards, tom lane