Re: inet/cidr type comparisons - Mailing list pgsql-hackers

From Alex Pilosov
Subject Re: inet/cidr type comparisons
Date
Msg-id Pine.BSO.4.10.10106111218170.16686-100000@spider.pilosoft.com
Whole thread Raw
In response to Re: inet/cidr type comparisons  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: inet/cidr type comparisons  (Jim Mercer <jim@reptiles.org>)
Re: inet/cidr type comparisons  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
This behaviour makes harder to use index to optimize a << b

What I have right now is rewriting a <<= b to use index plan :
(a >= network(b)) && ( a <= broadcast(b) )

However, that breaks down, since (for example) 

if a=10.1.2.3/32 and b = 10.1.2.0/24, broadcast(b) will be 10.1.2.255/24,
but 10.1.2.255/24 is considered to be less than 10.1.2.3/32...

I can work around this, however, the concept just didn't make sense to me,
but I see that for some people it does, so I'll live with it :)

So what I'm going to do then is to make a function set_masklen(inet|cidr,
int4) which would take an existing address and return a new value with
changed masklen.

Also, I'd like to create casting functions from varchar to inet/cidr,
since they are missing. Functions I'm writing:

varchar_inet(varchar)
varchar_cidr(varchar)
varchar_inet(varchar, int4)
varchar_cidr(varchar, int4)

(the last two variants will take masklen as a separate argument)

Does this look good? Actually, what's more advisable for these functions,
doing conversions from varchar or doing it from text?

Apologies for asking so many questions, but I'd like a sanity check before
proceeding :)

Thanks
-alex


On Mon, 11 Jun 2001, Tom Lane wrote:

> Alex Pilosov <alex@pilosoft.com> writes:
> > I noticed current wierd behaviour of a less/greater than comparisons of
> > things involving inet/cidr:
> 
> > 10.1.2.3/8 is considered to be less than 10.0.0.0/32
> 
> And what's wrong with that?  Essentially this comes from the conclusion
> that 10/8 is less than 10.0.0.0/32, which I have no problem with.
> 
> > To me, this makes no sense. I think b and c should be transposed, and
> > netmask comparison must be only used as a tiebreaker when the values are
> > the same otherwise (such as, when comparing 10.1.2.3/8 and 10.1.2.3/32).
> 
> That would break the rule that network part is major sort key and host
> part is minor sort key, which I think is useful behavior.
> 
> > For type cidr, same thing applies: currently, 10.1.2.0/24 is considered to
> > be less than 10.0.0.0/8. 
> 
> It is?
> 
> regression=# select '10.1.2.0/24'::cidr < '10.0.0.0/8'::cidr;
>  ?column?
> ----------
>  f
> (1 row)
> 
> 
>             regards, tom lane
> 
> 



pgsql-hackers by date:

Previous
From: mlw
Date:
Subject: OID Wrap
Next
From: Tom Lane
Date:
Subject: Catalog index cleanup blitz planned