Re: Summary: what to do about INET/CIDR

Please read below if the whole thing with inet/cidr doesn't make you puke
yet ;) The semi-longish proposal is at the bottom.

On Fri, 27 Oct 2000, Tom Lane wrote:

> Alex Pilosov <alex(at)pilosoft(dot)com> writes:
> > We should have as much error-checking as possible.
>
> How so? Without a netmask you have no way to know if it's a broadcast
> address or not. 10.0.0.255/32 might be a perfectly valid host address
> in, say, 10.0/16. But 10.0.0.255/24 is recognizably the broadcast
> address for 10.0.0/24 (and not for any other network...)
Right, that's what I'm trying to say: It shouldn't allow you to use
10.0.0.255/24 as a host address, but it should allow you to use
10.0.0.255/16

> > (ie. broadcast() function must return a value with /32 mask)
>
> I don't disagree with that part, but that's only because I see
> broadcast() as mainly a display convenience. If we had a larger and
> more thoroughly worked out set of inet/cidr operators, I'd be inclined
> to argue that broadcast('10.0.0.0/24') should yield 10.0.0.255/24 for
> computational convenience. Then we'd need to offer a separate function
> that would let you strip off the netmask for display purposes (actually
> host() would do for that...)

Actually, now that I think longer about the whole scheme in terms of
actual IP experience, here are my ideas:
a) inet is crock. I don't know anyone who would need to _care_ about a
netmask of a host, who wouldn't have a lookup table of networks/masks.
(Think /etc/hosts, and /etc/netmasks).

Storing a netmask of a network in a inet actually violates the relational
constraints: netmask is not a property of an IP address, its a property of
a network.

99% of people who would be storing IP addresses into postgres database
really do not know nor care what is a netmask on that IP. Only people who
would care are ones who store their _internal_ addresses (read: addresses
used on networks they manage). There is usually a very limited number of
such networks (<1000).

It makes no sense to have in database both 10.0.0.1/24 and 10.0.0.2/16.
None whatsoever.

This does NOT apply to CIDR datatype, as there are real applications (such
as storing routing tables) where you would care about netmask, but won't
care about a host part.

What I am suggesting is we do the following:
a) inet will NOT have a netmask

b) all the fancy comparison functions on inet should be deleted.
(leave only > >= = <= <)

c) the only things you can do on inet is to convert it to 4 octets (of
int1), to a int8, and to retrieve its network from a table of networks.

d) have a table, 'networks' (or any other name, maybe pg_networks?) which
would have one column 'network', with type cidr.
create table networks (network cidr not null primary key)

e) have a function network(inet) which would look up the address in a
table of networks using longest-prefix-match. I.E. something similar to:

select network from networks
where $1<<network
order by network_prefix(network)
desc limit 1;

I realise that this sounds a little bit strange after all the arguments
about inet, but if you think about it, this is the only sane way to deal
with these datatypes.

Right now, the datatypes we have look and sound pretty but are pretty much
useless in reality. Yes, it is nice to be able to store a netmask with
every IP address, it is useless in reality. (Yes, please, someone tell me
if you are using inet with netmasks and you actually like it).

I'd especially like to get input of Marc on this, as he's both a core team
member and has actual networking background...Oh yeah, if Marc can comment
on whether 10/8 or 10.0.0.0/8 is a proper way to represent a network, it'd
be great too :)