Re: Repair plan for inet and cidr types

From: Sevo Stille <sevo(at)ip23(dot)net>
To: "D'Arcy J(dot)M(dot) Cain" <darcy(at)druid(dot)net>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Repair plan for inet and cidr types
Date: 2000-07-05 10:38:25
Message-ID: 39631021.2881941B@ip23.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)ip23(dot)net

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Hannu Krosing 2000-07-05 11:24:42 Re: Article on MySQL vs. Postgres
Previous Message Jan Wieck 2000-07-05 10:06:49 Re: current CVS: undefined reference to `PGLZ_RAW_SIZE'