Re: Summary: what to do about INET/CIDR

Alex Pilosov <alex(at)pilosoft(dot)com> writes:
> On Fri, 27 Oct 2000, Tom Lane wrote:
>> BTW, does it strike anyone else as peculiar that the host(),
>> broadcast(), network(), and netmask() functions yield results
>> of type text, rather than type inet?

> I absolutely agree, except for network(), which should return cidr.

We could do that, but if we did, it would print out per CIDR format
(eg, '192.1/16') whereas both you and Larry have been saying you want
a way to produce '192.1.0.0/16'. Perhaps we need two functions, one
to produce the network in CIDR notation and one to produce it in INET
notation.

For that matter, perhaps we should not change host() to accept CIDR
but instead provide a separate function that does what I proposed
host() should do with a CIDR. Not sure.

> As I mentioned in another email, should inet datatype really care whether
> host part is all-ones or all-zeros and reject that?

I'm inclined to think not, partially because that would mean that the
results of broadcast() and network() could *NOT* be considered valid
INET values.

The way I'm visualizing this, INET is a generalized type that will store
any 4-octet address plus any netmask width from 1 to 32. This includes
not only host addresses, but network specs and broadcast addresses.
CIDR is a subset type that only accepts valid network specs (ie, no
nonzero address bits to the right of the netmask). There is no subset
type that corresponds to "valid host addresses only" --- if there were,
it would be a subset of INET but would have no valid values in common
with CIDR. We could make such a type but I dunno if it's worth the
trouble.

regards, tom lane