Second proposal: what to do about INET/CIDR

Sigh ... I was really hoping not to get drawn into fixing these issues
for 7.1, but ...

It seems like much of the problem is that there isn't any easy way to
choose between CIDR-style display format ('127.1/16') and INET-style
format ('127.1.0.0/16'). We need to bite the bullet and add conversion
functions, so that people can pick which they want.

Picking and choosing among the ideas discussed, here's my stab at a
complete proposal:

1. CIDR-type values will be displayed in "abbreviated" format, eg
"127.1/16". Since a CIDR value is no longer allowed to have any
nonzero bits to the right of the mask, no information is lost by
abbreviation. The /n will appear even when it is 32.

2. INET-type values will always be displayed with all octets, eg
"127.1.0.0/16". The /n part will be suppressed from display
if it is 32. INET will accept any octet pattern as an address
together with any netmask length from 1 to 32.

3. We will add explicit functions cidr(inet) and inet(cidr) to force
the data type to one or the other style, thus allowing selection
of either display style. Note that cidr(inet) will raise an error
if given something with nonzeroes to the right of the netmask.

4. The function host(inet) will now return inet not text. It will
take the address octets of the given value but force the netmask to 32
and the display type to INET. So for example host('127.1/16'::cidr)
will yield '127.1.0.0/32'::inet, which if displayed will appear
as just '127.1.0.0', per item 2.

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. After
more thought about my last message, 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 inet format, you'd
write inet(network(foo)) --- yielding '127.1.0.0/16'. If you want it
displayed with no netmask, write host(network(foo)) --- result
'127.1.0.0'.

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 will be applied to either inet or cidr columns
without any type conversion. (In other words, cidr(inet) and
inet(cidr) will only be applied if *explicitly* invoked.) I am not
convinced whether this is a good thing. In this proposal, no system
function except display will care whether its input is inet or cidr,
so the lack of conversion doesn't matter. But in the long run it
might be better to remove the binary-equivalence. Then, for example,
host(cidr) would be implemented as host(inet(cidr)), costing an extra
function call per operation. Right now I don't think we need to pay
that price, but maybe someday we will.

Thoughts?

regards, tom lane