Re: [HACKERS] cidr - Mailing list pgsql-hackers

Thus spake Bruce Momjian
> > Right but a netmask could be specified as 255.255.255.0/32.  Better yet,
> > if all you want to store is a netmask in a field, use an int.  Every
> > netmask can be specified in dotted notation or as a mask length.
>
> But we want the int to print as a IP address, and I don't think we want
> two types for IP addresses.  Too messy.

Well, sure.  In that case use the first form.  I can't actually think
of any case where I would need to store netmasks independently of hosts
in any case.  I'm just pointing out alternate ways to store it if you
can think of any use for such a thing.

> > Why bother with the addr len?  Just expand it out with zeroes before
> > storing it.
>
> 192.0.0.1 and 192.0.0.1.0.0 are different because one is IPv6, and the
> other is not.  We must keep that distinction stored somewhere.  Might
> was well use eight bytes.  The padding is going to take that much in
> most cases anyway, unless they use char (length of 1) or int2 after the
> field.

Yes, I am not as up on IPv6 as I would like to be.  However, I thought
that IPv6 addresses were IPv4 addresses with extra octets *pre*pended.
Anyway, I suspect that either way the IPv6 addresses would have non
zero bits added so zeroes in the extra bits could be the flag for IPv4
addresses.

Hmm.  How do we handle the different sized netmask lengths?

> > Maybe we could make cidr bits equal to -1 if we are storing a host with
> > indeterminate netmask rather than setting it to 32.  That allows us
> > to specify raw IP numbers without faking a netmask.
>
> Yes, that was the idea.  No one wants to see a netmask of
> 255.255.255.0/32.  I don't want to field those support e-mails.

Again, storing netmasks themselves seems so anomalous that I do tend
to not worry to much about it.  Normally if we are interested in a
netmask we are also interested in the host IP so we would store
something like "192.3.4.5/24" and, if we need the netmask, use the
netmask function.

    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

and perhaps;

    class('192.3.4.5/24::cidr') == C
    classnet('192.3.4.5/24::cidr') == 192.3.4

> Not sure if storing both IP and netmask in the same field is wise.  You
> would have:

I thought that that was the idea to begin with.

>     192.0.0.3/24    cidr
Right.

>     192.0.0.3:255.255.0.0   host/netmask
Converted internally to 192.0.0.3:/16

>     192.0.0.3    host, implied netmask A,B,C class?
Letting this convert automatically to a C class may not be what was
desired.  Better to specify the netmask.  You may be subnetting it
or even supernetting it.

>     192.0.0.3/32    host?
I would suggest that 192.0.0.3 should be the same thing unless we have
a mask len of -1 to signal indeterminate mask length in which case
192.0.0.3 gets converted internally to 192.0.0.3/-1.  Further, printing
a cidr with mask len of 32 (or -1) should print as if the host function
were called, that is don't print the network info in such cases.

>     192.0.0.3/32:255.255.255.0  host?/netmask
But 192.0.0.3/24 or 192.0.0.3:255.255.255.0 gives all the information
that you need.

> > to display it.  It's like using int to store both ID numbers and counts.
> > The database doesn't need to know the difference because we use any
> > particular field to store one or the other.
>
> Printing?

You mean printing netmasks?  As I said, it seems to me that netmasks will
always be paired with a host or network but perhaps we can set up the
function table so that netmask on an integer type converts to a netmask
in the form you suggest.  That would be the truly oo way to do it.

--
D'Arcy J.M. Cain <darcy@{druid|vex}.net>   |  Democracy is three wolves
http://www.druid.net/darcy/                |  and a sheep voting on
+1 416 424 2871     (DoD#0082)    (eNTP)   |  what's for dinner.