Skip site navigation (1) Skip section navigation (2)

Re: Summary: what to do about INET/CIDR

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Larry Rosenman <ler(at)lerctr(dot)org>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Summary: what to do about INET/CIDR
Date: 2000-11-03 21:19:59
Message-ID: 8203.973286399@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Larry Rosenman <ler(at)lerctr(dot)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 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. 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 appear in the result.
   Note that the system will consider this function to be a typecast,
   so the same result can be gotten with 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 bits to the right
   of the netmask to 1.  The display type will be set to inet.  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 a different
   format, write host(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 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 can be applied to either inet or cidr columns.

Comments?

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: Mikheev, VadimDate: 2000-11-03 21:23:58
Subject: RE: Alternative database locations are broken
Previous:From: Peter EisentrautDate: 2000-11-03 21:09:41
Subject: Alternative database locations are broken

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group