Thus spake Bruce Momjian
> > Thus spake Bruce Momjian
> > > Table with an element of type inet, will show "0.0.0.0/0" as "00/0"
> >
> > Is that an error? From the discussions with Paul Vixie, I think that
> > that is the correct way to output it. Note that you can always use
> > host() to get the full string for the host part at least.
>
>
> Well, if you say it OK, that's good enough for me. Item removed. It
> just looked strange, the 00/0. Can you explain why it should look like
> that. Just curious.
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.
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.
--
D'Arcy J.M. Cain <darcy@{druid|vex}.net> | Democracy is three wolves
http://www.druid.net/darcy/ | and a sheep voting on
+1 416 424 2871 (DoD#0082) (eNTP) | what's for dinner.
