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 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Mikheev, Vadim | 2000-11-03 21:23:58 | RE: Alternative database locations are broken |
Previous Message | Peter Eisentraut | 2000-11-03 21:09:41 | Alternative database locations are broken |