Re: [HACKERS] Definitional issue for INET types

Sevo Stille <sevo(at)ip23(dot)net> writes:
>> Hmm. One way to throw the question into stark relief is to ask:
>> Is '10/8' *equal to* '10.0.0.0/32', in the sense that unique indexes
>> and operations like SELECT DISTINCT should consider them identical?
>> Does your answer differ depending on whether you assume the values
>> are of CIDR or INET type?

> Well, in a CIDR context, they positively are different, '10.0.0.0/32' is
> a host, and '10/8' is a network, and our application would positively
> treat either entirely different. CIDR consistently works by
> apply-mask-and-process.

OK. Now let's try you on this one: true or false?
'10.1.2.3/8'::cidr = '10/8'::cidr

(which was actually the example I meant to ask about above, but
carelessly cut-and-pasted the wrong values :-(.)

> In a INET context, the answer is not that easy, as net and mask have no
> defined behaviour as a tuple. The mask will in some cases be a
> independent entity, which presumably is why Paul Vixie made meaningless
> net/mask combinations legal there.

I think that was the idea, all right, which would seem to suggest that
we ought to compare all the bits of the IP addresses, and then compare
the bitcounts (since the bitcount is just a compact representation of a
logically separate netmask, and has nothing to do with the validity of
the IP address). But I'm not sure whether this holds good for CIDR too.

> Personally, I am all for dropping INET, or for defining it to be
> maskless (which could be done by forcing /32 for it).

If you don't need a mask, leave out the /32 --- or even add a column
constraint requiring it to be 32. I don't see that it's necessary
to tell other people that they can't have a mask. CIDR may be a
different story however.

regards, tom lane