From: | Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
To: | hackers(at)PostgreSQL(dot)org |
Subject: | Re: [HACKERS] Open 6.5 items |
Date: | 1999-05-25 03:34:47 |
Message-ID: | 199905250334.XAA02534@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> 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(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 1999-05-25 03:57:50 | INET type and 00/0 |
Previous Message | D'Arcy J.M. Cain | 1999-05-25 03:17:23 | Re: [HACKERS] Open 6.5 items |