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
Re: inet/cidr type comparisons |
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: