Re: [HACKERS] inet/cidr

2006-12-21 Thread Andrew - Supernews
> "Worky" == Worky Workerson <[EMAIL PROTECTED]> writes: Worky> I was looking at upgrading to 8.2, but I make extensive use of Worky> the IP4 module. The needed changes to ip4r to build on 8.2 are already in its CVS, and as far as I know works, the only reason I've not done another release

[HACKERS] inet/cidr

2006-12-20 Thread Worky Workerson
I was looking at upgrading to 8.2, but I make extensive use of the IP4 module. It doesn't make properly due to the changes in the inet/cidr types, notably the removal of the type (is_cidr) field of the inet_struct, which the module uses when casting: ip4_cast_to_cidr, ip4r_cast_to_cidr, and a ch

Re: [HACKERS] inet/cidr wierdness (casting)

2001-06-12 Thread Tom Lane
Alex Pilosov <[EMAIL PROTECTED]> writes: > Apparently, since there's no explicit function to cast from inet to cidr, > postgresql assumes its always safe to do so, as they are > binary-compatible. Yes. I've thought for awhile that it was a mistake to treat them as binary-compatible. However, yo

Re: [HACKERS] inet/cidr type comparisons

2001-06-11 Thread Tom Lane
Alex Pilosov <[EMAIL PROTECTED]> writes: > On Mon, 11 Jun 2001, Tom Lane wrote: >> While there may not be a user-visible function for next-network-part, >> that hardly matters since the special-indexqual stuff isn't user-visible >> either. > Well, since I'm making an indexqual clause, I do need a

Re: [HACKERS] inet/cidr type comparisons

2001-06-11 Thread Tom Lane
Jim Mercer <[EMAIL PROTECTED]> writes: > while you are in there, can you cahnge the print functions so that they > are consistent? I believe they are consistent in 7.1; leastwise, you will have to make a pretty good argument why we should change them again. We had a very long discussion that led

Re: [HACKERS] inet/cidr type comparisons

2001-06-11 Thread Tom Lane
Alex Pilosov <[EMAIL PROTECTED]> writes: > 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 i

Re: [HACKERS] inet/cidr type comparisons

2001-06-11 Thread Tom Lane
Alex Pilosov <[EMAIL PROTECTED]> 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 1