Re: Summary: what to do about INET/CIDR

* Tom Lane <tgl@sss.pgh.pa.us> [001026 18:46]:
> After reviewing a number of past threads about the INET/CIDR mess,
> I have concluded that we should adopt the following behavior:
> 
> 1.  A data value like '10.1.2.3/16' is a legal INET value (it implies
> the host 10.1.2.3 in the network 10.1/16) but not a legal CIDR value.
> Hence, cidr_in should reject such a value.  Up to now it hasn't.
> 
> 2.  We do not have a datatype corresponding strictly to a host address
> alone --- to store a plain address, use INET and let the mask width
> default to 32.  inet_out suppresses display of a "/32" netmask (whereas
> cidr_out does not).
> 
> 3.  Given that CIDRs never have invalid bits set, we can use the same
> ordering rules for both datatypes: sort by address part, then by
> number of bits.  This is compatible with what 7.0 did when sorting.
> It is *not* quite the same as what current sources do, but I will revert
> that change.
> 
> I didn't see anyone objecting to this scheme in past discussions, but
> I also didn't see any clear statement that all the interested parties
> had agreed to it.  Last chance to complain...
I'd like to see a way to get all 4 octets of a CIDR printed out... 

Also a way to get network (.0) and broadcast (all ones) for a cidr
block out of our stuff. 

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