Thread

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

Frank Cusack <fcusack@iconnet.net> — 1999-11-11T20:50:59Z

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@krs.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@krs.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