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
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
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
> 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
In response to
pgsql-hackers by date
|Next:||From: Peter Eisentraut||Date: 2000-10-28 16:20:18|
|Subject: Re: Idea: cross-check versions during initdb |
|Previous:||From: Larry Rosenman||Date: 2000-10-28 15:52:43|
|Subject: Re: more multibyte/After TGL...|