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

From Sevo Stille
Subject Re: Repair plan for inet and cidr types
Date
Msg-id 39631021.2881941B@ip23.net
Whole thread Raw
In response to Re: Repair plan for inet and cidr types  (darcy@druid.net (D'Arcy J.M. Cain))
List pgsql-hackers
"D'Arcy J.M. Cain" wrote:

> > This has also been a source of problems. I propose that cidr and inet are
> > not made equivalent types at any level. No automatic casting either. A
> > network and a host are not the same thing. To construct a cidr value from
> > an inet value, you'd have to use some sort of (to be created) network()
> > function, e.g., network('127.0.0.5/16') => '127.0/16'. IMO, there is no
> > reasonable way to construct an inet value from a cidr value.
> 
> 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.

Given that only contains is a reasonable cidr vs. inet comparison, we
should not cast automatically - both the network >> network and network
>> host comparison are legitimate. 

> > * Operators
> >
> > Because the types are equivalent, the operators have also been bunched
> > together in confusing ways. I propose that ordering operators (>, +, <)
> > between inet and cidr be eliminated, they do not make sense. The only
> > useful operation between cidr and inet is the << ("contains") operator.
> > Ordering withing cidr and inet be defined in terms of their bit
> > representation, as is the case now. The << family of operators should also
> > be removed for the inet type -- a host cannot "contain" another host. What
> > you probably wanted is `inet1 << network(inet2)'.
> 
> 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."  

If you do not mean "network(inet1) <<= network(inet2)" but rather
"host(inet1) << network(inet2)", yes.

> In fact, if we define << as only allowed
> between inet and cidr (or cidr and cidr?) then the implied cast will
> deal with it if that cast causes the host bits to drop as suggested
> above.

Right. The containing side must be a network, so we can implicitly cast
that. The contained side has to be taken as-is - if a network vs.
network comparison is intended, the user must explicitly cast it. 

Sevo

-- 
Sevo Stille
sevo@ip23.net


pgsql-hackers by date:

Previous
From: JanWieck@t-online.de (Jan Wieck)
Date:
Subject: Re: Revised Copyright: is this more palatable?
Next
From: The Hermit Hacker
Date:
Subject: Re: Article on MySQL vs. Postgres