Re: uniqueness not always correct

Bruce Momjian <pgman@candle.pha.pa.us> writes:
> This bug appears to still exist in 7.0:
>     test=> create table test (zone int4, net cidr, unique(zone, net));

Yeah.  IIRC, the issue is that the CIDR data-type-specific btree
comparison function looks at all bits in the datatype, including bits
that are past the specified length (/24, here) and weren't necessarily
zeroed by the datatype input routine.  It's not clear whether the
comparator or the input routine or both are wrong --- *should* those
bits be significant, or not?

The discussion about how to fix it bogged down, and apparently
no one did anything.  I recall feeling that we had some confusion
between what the semantics of CIDR and INET types ought to be,
but I don't understand them well enough to know what they should do.
Right now the same operators are used for both, which seems like it
can't be right.

I was hoping someone would dig through the archives or talk to Paul
Vixie again and come away with a clear understanding of the semantics
of these two datatypes (and why we need two, if we do).

Alternatively, if no one cares enough about these types to even
understand what they should do, maybe we should rip 'em out?

            regards, tom lane