Re: Summary: what to do about INET/CIDR
От | Dominic J. Eidson |
---|---|
Тема | Re: Summary: what to do about INET/CIDR |
Дата | |
Msg-id | Pine.LNX.4.10.10010281059220.26046-100000@morannon.the-infinite.org обсуждение исходный текст |
Ответ на | Re: Summary: what to do about INET/CIDR (Alex Pilosov <alex@pilosoft.com>) |
Список | 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/
В списке pgsql-hackers по дате отправления: