Re: Repair plan for inet and cidr types - Mailing list pgsql-hackers

From eisentrp@csis.gvsu.edu
Subject Re: Repair plan for inet and cidr types
Date
Msg-id Pine.LNX.4.21.0007050842080.10677-100000@eos05.csis.gvsu.edu
Whole thread Raw
In response to Re: Repair plan for inet and cidr types  (darcy@druid.net (D'Arcy J.M. Cain))
Responses Re: Repair plan for inet and cidr types  (darcy@druid.net (D'Arcy J.M. Cain))
List 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 by date:

Previous
From: Egon Schmid
Date:
Subject: Re: Article on MySQL vs. Postgres
Next
From: "Peter Galbavy"
Date:
Subject: Re: Article on MySQL vs. Postgres