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
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' |