Re: Summary: what to do about INET/CIDR - Mailing list pgsql-hackers

Larry Rosenman <ler@lerctr.org> writes:
> What was the final outcome?

I don't think we'd quite agreed what to do.  The proposed code changes
are not large, we just need a consensus on what the behavior ought to
be.

Since a couple of people objected to the idea of using casts to control
the output format, here is a strawman Plan C for discussion.  This
differs from my last proposal in that the inet() and cidr() pseudo
cast functions are gone, and there are two functions returning text
values that can be used if you don't like the default display formats.

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. The function host(inet) will return a text representation of  just the IP part of an INET or CIDR value, eg,
"127.1.0.0". All four octets will always appear, the netmask will never appear.  (This is the same as its current
behavior,I think.)
 

4. A new function text(inet) will return a text representation of  both the IP and netmask parts of an INET or CIDR
value,eg,  "127.1.0.0/16".  Unlike the default display conversions, all four  octets and the netmask length will always
appearin the result.  Note that the system will consider this function to be a typecast,  so the same result can be
gottenwith inetval::text or  CAST(inetval AS text).
 

[ the rest is the same as in my last proposal: ]

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.  I am  inclined to have it return the
samemasklength as the input, so for  example broadcast('127.1/16') would yield '127.1.255.255/16'::inet.  If you want
thebroadcast address displayed without a netmask  notation, you'd need to write host(broadcast(foo)).  Alternatively,
wecould 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
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 a different  format,
writehost(network(foo)) or text(network(foo)).
 

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 can be applied to
eitherinet or cidr columns.
 

Comments?
        regards, tom lane