Skip site navigation (1) Skip section navigation (2)

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

From: Frank Cusack <fcusack(at)iconnet(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Vadim Mikheev <vadim(at)krs(dot)ru>, pgsql-bugs(at)postgreSQL(dot)org, PostgreSQL Developers List <hackers(at)postgreSQL(dot)org>
Subject: Re: [HACKERS] Re: [BUGS] uniqueness not always correct
Date: 1999-11-11 20:50:59
Message-ID: 199911112050.MAA08142@yem.jsv.qwest.net (view raw or flat)
Thread:
Lists: pgsql-bugspgsql-hackers
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

pgsql-hackers by date

Next:From: Stephen MartinDate: 1999-11-11 21:00:57
Subject: Error on db recovery..
Previous:From: Theo KramerDate: 1999-11-11 20:50:14
Subject: Re: [HACKERS] Slow - grindingly slow - query

pgsql-bugs by date

Next:From: fredrik chabotDate: 1999-11-11 23:58:57
Subject: subscribe
Previous:From: Tom LaneDate: 1999-11-11 16:57:59
Subject: Re: [HACKERS] Re: [BUGS] uniqueness not always correct

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group