> I'm not sure why "00/0" rather than "0/0" but basically you don't have
> to show more octets than necessary based on the netmask. For example,
> a netmask of 32 bits requires all 4, 24 bits requires 3, 16 needs 2
> and 8 (and less) needs 1. Technically you don't even need 1 octet for
> 0 bits I suppose but "/0" doesn't make much sense.
Well, then it is a bug. It should show 00/0.
>
> This is all based on my understanding. RFC lawyers, please feel free to
> correct me.
>
> > > > When creating a table with either type inet or type cidr as a primary,unique
> > > > key, the "198.68.123.0/24" and "198.68.123.0/27" are considered equal
> > >
> > > I guess I'll take a stab at it. I just need to know which of the following
> > > is true.
> > >
> > > 198.68.123.0/24 < 198.68.123.0/27
> > > 198.68.123.0/24 > 198.68.123.0/27
> > >
> > > Also, is it possible that the current behaviour is what we want? It seems
> > > to me that if you make a network a primary key, you probably want to prevent
> > > overlap. What we have does that.
> >
> > Good question. If we decide the current behaviour is OK, that is fine
> > with me. Someone know understand this just needs to say so.
>
> And if not, what is the answer to the above question.
Don't know.
-- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610)
853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill,
Pennsylvania19026
