Re: uniqueness not always correct
От | Tom Lane |
---|---|
Тема | Re: uniqueness not always correct |
Дата | |
Msg-id | 12455.959825587@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: uniqueness not always correct (Bruce Momjian <pgman@candle.pha.pa.us>) |
Ответы |
Re: uniqueness not always correct
|
Список | pgsql-bugs |
Bruce Momjian <pgman@candle.pha.pa.us> writes: > This bug appears to still exist in 7.0: > test=> create table test (zone int4, net cidr, unique(zone, net)); Yeah. IIRC, the issue is that the CIDR data-type-specific btree comparison function looks at all bits in the datatype, including bits that are past the specified length (/24, here) and weren't necessarily zeroed by the datatype input routine. It's not clear whether the comparator or the input routine or both are wrong --- *should* those bits be significant, or not? The discussion about how to fix it bogged down, and apparently no one did anything. I recall feeling that we had some confusion between what the semantics of CIDR and INET types ought to be, but I don't understand them well enough to know what they should do. Right now the same operators are used for both, which seems like it can't be right. I was hoping someone would dig through the archives or talk to Paul Vixie again and come away with a clear understanding of the semantics of these two datatypes (and why we need two, if we do). Alternatively, if no one cares enough about these types to even understand what they should do, maybe we should rip 'em out? regards, tom lane
В списке pgsql-bugs по дате отправления: