Re: Repair plan for inet and cidr types

Поиск
Список
Период
Сортировка
От eisentrp@csis.gvsu.edu
Тема Re: Repair plan for inet and cidr types
Дата
Msg-id Pine.LNX.4.21.0007050842080.10677-100000@eos05.csis.gvsu.edu
обсуждение исходный текст
Ответ на Re: Repair plan for inet and cidr types  (darcy@druid.net (D'Arcy J.M. Cain))
Ответы Re: Repair plan for inet and cidr types  (darcy@druid.net (D'Arcy J.M. Cain))
Список pgsql-hackers
On Tue, 4 Jul 2000, D'Arcy J.M. Cain wrote:

> I'm not sure I understand why this is necessary.  I can see not allowing
> cidr ==> inet conversions but inet ==> cidr can be done as it is a matter
> of dropping information - the host part.

Automatic casts should not lose information. How would you feel if floats
were automatically rounded when you store them into int fields? I think
this is an important principle in any type system.

> Then let's define that as the meaning of "inet1 << inet2" i.e. define
> the << operator between inet types as meaning "tell me if inet1 is in
> the same network as inet2."

Again, let the user say what he wants: inet1 << network(inet2).

Also note that "is inet1 in the same network as inet2" is different from
"is inet1 contained in the network of inet2" (which is what it does now).
The operator you defined is symmetric (if inet1 is in the same network as
inet2, then inet2 is also in the same network as inet1), whereas the << is
antisymmetric. In fact, AFAICT, the operator you defined doesn't exist
yet, although it perhaps should.


-- 
Peter Eisentraut                  Sernanders vaeg 10:115
peter_e@gmx.net                   75262 Uppsala
http://yi.org/peter-e/            Sweden



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Egon Schmid
Дата:
Сообщение: Re: Article on MySQL vs. Postgres
Следующее
От: "Peter Galbavy"
Дата:
Сообщение: Re: Article on MySQL vs. Postgres