Re: Summary: what to do about INET/CIDR

* Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> [001027 17:54]:
> 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.
I'd agree with this.
>
> 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.
True.
>
> 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.
I believe this is true. Now if we could get the output stuff so there
are BOTH ways of displaying the data (we seem to need both, from the
statements we get each time this has been brought up), such that you
can freely move between the 4-octet and short-octet (for lack of a
better term) version of a CIDR network spec.

Thanks for any consideration, and if this could make 7.1, I'd be most
appreciative...

Larry

>
> regards, tom lane
--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 (voice) Internet: ler(at)lerctr(dot)org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749