Re: [HACKERS] New IP address datatype
От | Bruce Momjian |
---|---|
Тема | Re: [HACKERS] New IP address datatype |
Дата | |
Msg-id | 199906011438.KAA24168@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] New IP address datatype ("D'Arcy" "J.M." Cain <darcy@druid.net>) |
Список | pgsql-hackers |
> Thus spake Tom Lane > > > Thus spake Mark Volpe > > >> Hosts are specified as '134.67.131.10' or '134.67.131.10/32' and > > >> display 134.67.131.10. > > > > Hmm. This suggests that the example given in the recent discussion > > about primary keys is bogus: 198.68.123.0/24 is never equal to > > 198.68.123.0/27, because they represent networks of different sizes. > > I don't think it's so clear cut. For INET, the two addresses refer > to the same host but contradict each other in network details. The > INET type is primarily a host type with optional network information > added. One might even argue that 198.68.123.1/24 and 198.68.123.2/27 > should not be allowed to coexist but that's probably going too far. > > For the CIDR type, they refer to two different networks but they overlap. > The argument is that as a primary key they partially conflict so they > shouldn't be allowed to coexist. > > > If you were talking about host addresses, then the netmask would be > > /32 in both cases, and so the issue doesn't arise. > > Right. For the INET type the netbits defaults to /32 so it can be used > for hosts transparently. > > > I'm back to the opinion that netmask does matter in comparisons and in > > indexes ... but I'd sure like to hear what Vixie has to say about it. > > I have asked him. > > > BTW, if we did want to make INET and CIDR have different behavior in > > comparisons and indexes, that would mean having two sets of operators > > listed in the system catalogs. We cannot add that as a post-6.5 patch > > because it would require an initdb, which is one of the things we don't > > do between major releases. If it's wrong (I'm not convinced) we must > > either fix it this week or live with it till 6.6 ... > > At this point I doubt we want to start mucking with catalogues and new > operators. Fixing it to be consistent is probably doable. > > And since I will never use either type as a primary key, I can live > with either decision. :-) OK, but let's make a decision. -- 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
В списке pgsql-hackers по дате отправления: