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

Re: Summary: what to do about INET/CIDR

From: "Dominic J(dot) Eidson" <sauron(at)the-infinite(dot)org>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Summary: what to do about INET/CIDR
Date: 2000-10-28 16:17:30
Message-ID: Pine.LNX.4.10.10010281059220.26046-100000@morannon.the-infinite.org (view raw or flat)
Thread:
Lists: pgsql-hackers
On Fri, 27 Oct 2000, Alex Pilosov wrote:

> > BTW, does it strike anyone else as peculiar that the host(),
> > broadcast(), network(), and netmask() functions yield results
> > of type text, rather than type inet?  Seems like it'd be considerably
> > more useful if they returned values of type inet with masklen = 32
> > (except for network(), which would keep the original masklen while
> > coercing bits to its right to 0).
> I absolutely agree, except for network(), which should return cidr.
> (after all, this is the network).
> 
> As I mentioned in another email, should inet datatype really care whether
> host part is all-ones or all-zeros and reject that? It would make sense to
> me (10.0.0.0/8::inet is not a valid address, but 10.0.0.0/8::cidr is), but
> it would break some people's scripts...

How about letting inet just be a "simple" storage type for four octets
seperated by periods. (Along the line of (0-255) . (0-255) . (0-255) . (0-255) )

The only conversion function there would be that operates on inet is
cidr(inet) - which returns the contents of the tuple, with a /32.
Alternately, for those who think we absolutely need something more
complicated (I don't think it's neeccesary), something along the lines of:

cidr('10.20.23.252' => '10.20.23.252/32'
cidr('10.20.23.0') => '10.20.23/24' (or '10.20.23.0/24')
cidr('10.20.0.0') => '10.20/16' (or '10.20.0.0/16')
cidr('10.0.0.0') => '10/8' (or '10.0.0.0/8')

Although one should put a comment/warning in the documentation that cidr()
assumes subnets to be on an octet boundary. (Which is the norm with inet
stuff - cidr was created specifically to get away from
subnet-on-octet-boundaries.)

Slight digression - on the discussion whether it's 127/8, or 127.0.0.0/8 -
both are accepted in most applications nowadays. But back to the issue
at hand...

Then let the cidr data type be for anything more advanced - like for
storing subnets on non-octet boundaries etc, and have host(),
broadcast(), network(), and netmask() functions. host() would return the
IP with a /32 mask - and inet(cidr) would just return the IP, without a
mask.

> I'm talking here from a perspective of a network provider with P
> knowledge...I'm sure Marc can chime in here...

So am I.

-- 
Dominic J. Eidson
                                        "Baruk Khazad! Khazad ai-menu!" - Gimli
-------------------------------------------------------------------------------
http://www.the-infinite.org/              http://www.the-infinite.org/~dominic/


In response to

pgsql-hackers by date

Next:From: Peter EisentrautDate: 2000-10-28 16:20:18
Subject: Re: Idea: cross-check versions during initdb
Previous:From: Larry RosenmanDate: 2000-10-28 15:52:43
Subject: Re: more multibyte/After TGL...

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