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 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
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/
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2000-10-28 16:20:18 | Re: Idea: cross-check versions during initdb |
Previous Message | Larry Rosenman | 2000-10-28 15:52:43 | Re: more multibyte/After TGL... |