Second proposal: what to do about INET/CIDR - Mailing list pgsql-hackers

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
tohave any  nonzero bits to the right of the mask, no information is lost by  abbreviation.  The /n will appear even
whenit 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
allowingselection  of either display style.  Note that cidr(inet) will raise an error  if given something with
nonzeroesto 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
forcethe 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
bitsto 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
losesvaluable  functionality.
 

6. The function network(inet) will now return cidr not text.  The result  has the same masklen as the input, with bits
tothe 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
writeinet(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
tothe right, and  output display type and masklen set to inet and 32.  For example,  netmask('127.1/16') =
'255.255.0.0/32'::inetwhich 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
eitherinet or cidr columns  without any type conversion.  (In other words, cidr(inet) and  inet(cidr) will only be
appliedif *explicitly* invoked.)  I am not  convinced whether this is a good thing.  In this proposal, no system
functionexcept display will care whether its input is inet or cidr,  so the lack of conversion doesn't matter.  But in
thelong run it  might be better to remove the binary-equivalence.  Then, for example,  host(cidr) would be implemented
ashost(inet(cidr)), costing an extra  function call per operation.  Right now I don't think we need to pay  that price,
butmaybe someday we will.
 

Thoughts?
        regards, tom lane