Re: [HACKERS] Definitional issue for INET types

Tom Lane wrote:

> Now, my understanding of things is that '10.1.2.3/8' is just an
> unreasonably verbose way of writing '10/8', because if you write /8
> you are saying that only the first 8 bits mean anything.  

Not really. In a classed view on a network, the /8 is undefined - and
worse, there is no real concept of a address consisting of a 
network/netmask tuple. /8 might imply that 10.1.2.3 is in the class A
segment, it might be considered a 255.0.0.0 netmask with any possible
interpretation of the latter, or it might be entirely ignored. For
::cidr vs. ::cidr the answer is clear - apply the masks and match then,
which would make 10/8 lesser by all means.

> So it seems
> to me that we are really comparing '10/8' and '10.0.0.0/32', and the
> former should be considered the lesser in the same way that 'ab'
> comes before 'abc' in dictionaries.
> 
> Is the regress test's expected output wrong, or have I missed
> something?

Tough question. There are some nasty details differing between classed
network notation and CIDR notation, and we certainly cannot reconcile
them all in operators. As the significant digits are meaningless in
classed notation, they might either be ignored or interpreted according
to any rule applying to classed netmasks, which really depends on the
context of the network device - a router, firewall or audit tool might
each have different semantics and requirements.  

I'll see whether I can figure out something consistent for the inet data
type. As it is right now, we might just as well drop it - it is both
synonymous to cidr and to a cidr /32 host, which simply can't be.
Personally, I don't think we would lose any functionality if we drop it,
as long as we have functions that return classed network structures like
the base address and a networks subnettable range. 

Sevo


-- 
Sevo Stille
sevo@ip23.net