Summary: what to do about INET/CIDR

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...
        regards, tom lane