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
>
>
