Re: [HACKERS] CIDR type and functions

D'Arcy J.M. Cain:

> netmask('192.3.4.5/24::cidr') == 255.255.255.0
> masklen('192.3.4.5/24::cidr') == 24
> host('192.3.4.5/24::cidr') == 192.3.4.5
> network('192.3.4.5/24::cidr') == 192.3.4.0
> broadcast('192.3.4.5/24::cidr') == 192.3.4.255
> and perhaps;
> class('192.3.4.5/24::cidr') == C
> classnet('192.3.4.5/24::cidr') == 192.3.4

Bruce Momjian:

> Yes, we need those. Code them up, and I will add them as standard
> types.

This is really all contrary to the concept of CIDR notation. While I
did end up calling the type INET instead of CIDR (which seemed to be
the consensus when the discussion was going on, because INET would be
more intuitively understandable by users than CIDR), I still stuck to
the behavior that Paul Vixie wanted: CIDR notation and representation.
It seemed to me that this was a good compromise, as it gives us a
clean, standards-based notation where host addresses are a functioning
special case. However, networks, netmasks, broadcast addresses and
interface addresses all need to be stored in separate INET values.

If what we actually want is what D'Arcy shows above, then we should
drop CIDR notation, stop using Paul Vixie's functions for dealing with
the same, and change the storage format to include more information,
and a different and more flexible input format. Just off the top of
my head, 'inet 158.37.96.1 netmask 0xffffff00 broadcast 158.37.96.255'
would be a cool input (and output) format to support. :-)

D'Arcy J.M. Cain:

> OK, I started but I could use a small change to inet_net_ntop.c [...]

I have to side with Paul on this one: that file and its companion with
the similar name were pulled in from the BIND distribution simply for
convenience, so we wouldn't have to insist that people must install
BIND from source to be able to install PostgreSQL. We really, really
shouldn't change them. If what we want is not what they implement, we
should drop them and implement what we want.

My vote (surprise! surprise!) goes toward keeping what we've got right
now. As Paul says, there's an RFC describing the behavior of the data
type as it now stands, and it's not as if it were difficult to do all
the other things one might want to do with it.

However, adding utility functions to do some of the things D'Arcy
suggests sounds good. I would think that they should be defined to
take INET parameters and return INET results, and the most useful ones
seem to me to be the following three (shown with various inputs):

netmask('158.37.96') ==> '255.255.255.0/32'
netmask('158.37.96/21') ==> '255.255.248.0/32'
broadcast('158.37') ==> '158.37.255.255/32'
broadcast('158.37.96') ==> '158.37.96.255/32'
broadcast('158.37.96/21') ==> '158.37.103.255/32'
network('158.37.96.15') ==> '158.37/16'

Note that the last one has to assume the old class A/B/C/D/E stuff.

-tih
--
Popularity is the hallmark of mediocrity. --Niles Crane, "Frasier"