Re: [HACKERS] Re: [BUGS] uniqueness not always correct

I'm not sure that a '<' comparison is really meaningful for inet/cidr?
At least not the '<' comparison you are doing. For networks (cf hosts),
the only really meanininful operators are '<<' (contained within), etc.

A nice easy fix might be to make sure that the unmasked portion of the
data is set to all 0's when storing the data.

~f
ps. I'm not subscribed to the lists so this will probably bounce. Please
repost for me.

>>>>> On Thu, 11 Nov 1999, "Tom" == Tom Lane wrote:

Tom> Vadim Mikheev <vadim(at)krs(dot)ru> writes:

+> Yes, I reproduced this (Solaris 2.5/sparc). Seems like CIDR
+> problem(??!):

Tom> Yes. Looks like the low-order bits of a CIDR address are garbage,
Tom> but network_cmp() compares them as though all bits are significant.
Tom> So, indeed, it may think two different instances of '1.2.3/24' are
Tom> not equal.

Tom> The regular inet comparison functions at least *try* to mask out
Tom> garbage bits, but I think they get it wrong too --- they should be
Tom> taking the smaller of ip_bits(a1) and ip_bits(a2) as the number of
Tom> bits to compare. They don't. Thus, for example,

Tom> regression=> select '1.2.5/16'::cidr < '1.2.3/24'::cidr;
Tom> ?column?
Tom> --------
Tom> f
Tom> (1 row)

Tom> which looks wrong to me.

Tom> In short, it's a bug in the inet data types, not a generic problem
Tom> with unique indexes.

Tom> regards, tom lane
>>>>> On Thu, 11 Nov 1999,
>>>>> "Tom" == Tom Lane wrote:

Tom> Vadim Mikheev <vadim(at)krs(dot)ru> writes:

+> Yes, I reproduced this (Solaris 2.5/sparc).
+> Seems like CIDR problem(??!):

Tom> Yes. Looks like the low-order bits of a CIDR address are garbage,
Tom> but network_cmp() compares them as though all bits are significant.
Tom> So, indeed, it may think two different instances of '1.2.3/24'
Tom> are not equal.

Tom> The regular inet comparison functions at least *try* to mask out
Tom> garbage bits, but I think they get it wrong too --- they should be
Tom> taking the smaller of ip_bits(a1) and ip_bits(a2) as the number of
Tom> bits to compare. They don't. Thus, for example,

Tom> regression=> select '1.2.5/16'::cidr < '1.2.3/24'::cidr;
Tom> ?column?
Tom> --------
Tom> f
Tom> (1 row)

Tom> which looks wrong to me.

Tom> In short, it's a bug in the inet data types, not a generic problem
Tom> with unique indexes.

Tom> regards, tom lane