Re: Summary: what to do about INET/CIDR

Agreed with all of it, but how about incorporating conversion from inet
to int8? (first octet*256*256*256+second octet*256*256+third
octet*256+fourth octet). 

This will allow to do a lot of magic with addresses using plain math.

Also, I'd still like netmask_length, length of netmask in bits.

-alex

On Fri, 3 Nov 2000, Tom Lane wrote:

> 5. The function broadcast(inet) will now return inet not text.  It
>    will take the given address octets and force the bits to the right
>    of the netmask to 1.  The display type will be set to inet.  I am
>    inclined to have it return the same masklength as the input, so for
>    example broadcast('127.1/16') would yield '127.1.255.255/16'::inet.
>    If you want the broadcast address displayed without a netmask
>    notation, you'd need to write host(broadcast(foo)).  Alternatively,
>    we could say that broadcast() always returns masklen 32, but I think
>    this loses valuable functionality.
> 
> 6. The function network(inet) will now return cidr not text.  The result
>    has the same masklen as the input, with bits to the right of the mask
>    zeroed to ensure it is a valid cidr value.  The display type will be
>    set to cidr.  For example, network('127.1.2.3/16') will yield
>    '127.1/16'::cidr.  To get this result displayed in a different
>    format, write host(network(foo)) or text(network(foo)).
> 
> 7. The function netmask(inet) will now return inet not text.  It will
>    return octets with 1s in the input's netmask, 0s to the right, and
>    output display type and masklen set to inet and 32.  For example,
>    netmask('127.1/16') = '255.255.0.0/32'::inet which will display as
>    '255.255.0.0'.  (I suppose a really anal definition would keep the
>    input masklen, forcing you to write host(netmask(foo)) to get a
>    display without "/n".  But I don't see any value in that for
>    netmasks.)
> 
> 8. Because we still consider inet and cidr to be binary-equivalent types,
>    all of these functions can be applied to either inet or cidr columns.
> 
> Comments?
> 
>             regards, tom lane
> 
>