cidr

From pgsql-hackers-owner+M4219@hub.org Tue Jul  4 20:10:16 2000
Received: from hub.org (root@hub.org [216.126.84.1])
	by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id UAA13204
	for <pgman@candle.pha.pa.us>; Tue, 4 Jul 2000 20:10:15 -0400 (EDT)
Received: from hub.org (majordom@localhost [127.0.0.1])
	by hub.org (8.10.1/8.10.1) with SMTP id e650A8S29252;
	Tue, 4 Jul 2000 20:10:08 -0400 (EDT)
Received: from merganser.its.uu.se (merganser.its.uu.se [130.238.6.236])
	by hub.org (8.10.1/8.10.1) with ESMTP id e6505pS14530
	for <pgsql-hackers@postgresql.org>; Tue, 4 Jul 2000 20:05:52 -0400 (EDT)
Received: from regulus.student.UU.SE ([130.238.5.2]:37402 "EHLO
        regulus.its.uu.se") by merganser.its.uu.se with ESMTP
	id <S176281AbQGEAFU>; Wed, 5 Jul 2000 02:05:20 +0200
Received: from peter (helo=localhost)
	by regulus.its.uu.se with local-esmtp (Exim 3.02 #2)
	id 139cnr-0003QO-00
	for pgsql-hackers@postgresql.org; Wed, 05 Jul 2000 02:12:35 +0200
Date:   Wed, 5 Jul 2000 02:12:35 +0200 (CEST)
From: Peter Eisentraut <peter_e@gmx.net>
To: PostgreSQL Development <pgsql-hackers@postgresql.org>
Subject: [HACKERS] Repair plan for inet and cidr types
Message-ID: <Pine.LNX.4.21.0007050118110.3542-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
X-Mailing-List: pgsql-hackers@postgresql.org
Precedence: bulk
Sender: pgsql-hackers-owner@hub.org
Status: OR

As we know, the inet and cidr types are still broken in several ways,
amongst others input and output functions, operators, ordering. I've
collected the bug reports from the last year or so from the archives.

There's apparently a lack of understanding of what exactly are these types
are supposed to do. Therefore, instead of addressing each bug
individually, let me first state what I reconstructed as the specification
of these types, and then add what is currently wrong with it.

* CIDR

The cidr type stores the identity of an IP _network_. A network
specification is of the form 'x.x.x.x/y'. The documentation states that if
y is omitted then it is constructed from the old A, B, C class scheme. So
be it. In a real world network, the bits (y+1)...32 have to be zero, but
the cidr type does not currently enforce this. This has been the source of
bugs in the past, and no doubt the source of some confusion as well. I
propose that cidr _reject_ input of the form '127.0.0.5/16'. If you think
about it, this is the same as int4 rejecting 3.5 as input.

* INET

The inet type stores the identity of an IP _host_. A host specification is
of the form 'x.x.x.x'. Optionally, the inet type also stores the identity
of the network the host is in. E.g., '127.0.0.5/16' means the host
127.0.0.5 in the network 127.0/16.

* Type equivalency

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.

* 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)'.


Does anyone see this differently? If not, can we agree on this
specification?

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


From pgsql-hackers-owner+M4230@hub.org Tue Jul  4 22:13:37 2000
Received: from hub.org (root@hub.org [216.126.84.1])
	by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id WAA13773
	for <pgman@candle.pha.pa.us>; Tue, 4 Jul 2000 22:13:37 -0400 (EDT)
Received: from hub.org (majordom@localhost [127.0.0.1])
	by hub.org (8.10.1/8.10.1) with SMTP id e652DSS19722;
	Tue, 4 Jul 2000 22:13:28 -0400 (EDT)
Received: from druid.net (root@druid.net [216.126.72.98])
	by hub.org (8.10.1/8.10.1) with ESMTP id e652D9S19504
	for <pgsql-hackers@postgresql.org>; Tue, 4 Jul 2000 22:13:09 -0400 (EDT)
Received: from localhost (4223 bytes) by druid.net
	via sendmail with P:stdio/R:bind_hosts/T:inet_zone_bind_smtp
	(sender: <darcy>) (ident <darcy> using unix)
	id <m139egU-000AXpC@druid.net>
	for <pgsql-hackers@postgresql.org>; Tue, 4 Jul 2000 22:13:06 -0400 (EDT)
	(Smail-3.2.0.109 1999-Oct-27 #3 built 2000-Jun-28)
Message-Id: <m139egU-000AXpC@druid.net>
From: darcy@druid.net (D'Arcy J.M. Cain)
Subject: Re: [HACKERS] Repair plan for inet and cidr types
In-Reply-To: <Pine.LNX.4.21.0007050118110.3542-100000@localhost.localdomain>
	"from Peter Eisentraut at Jul 5, 2000 02:12:35 am"
To: Peter Eisentraut <peter_e@gmx.net>
Date: Tue, 4 Jul 2000 22:13:06 -0400 (EDT)
CC: PostgreSQL Development <pgsql-hackers@postgresql.org>
X-Mailer: ELM [version 2.4ME+ PL78 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII
X-Mailing-List: pgsql-hackers@postgresql.org
Precedence: bulk
Sender: pgsql-hackers-owner@hub.org
Status: OR

Thus spake Peter Eisentraut
> There's apparently a lack of understanding of what exactly are these types
> are supposed to do. Therefore, instead of addressing each bug
> individually, let me first state what I reconstructed as the specification
> of these types, and then add what is currently wrong with it.

I have been browsing through the old messages on the topic.  There was, in
fact some very good work defining the type before anyone actually started
to code.  There was a surprising amount of controversy over the actual
definitions but I think in the end we hammered it out at least to the
point that everyone could work with it.

> * CIDR
> 
> The cidr type stores the identity of an IP _network_. A network
> specification is of the form 'x.x.x.x/y'. The documentation states that if
> y is omitted then it is constructed from the old A, B, C class scheme. So
> be it. In a real world network, the bits (y+1)...32 have to be zero, but
> the cidr type does not currently enforce this. This has been the source of
> bugs in the past, and no doubt the source of some confusion as well. I
> propose that cidr _reject_ input of the form '127.0.0.5/16'. If you think
> about it, this is the same as int4 rejecting 3.5 as input.

There is also the option of accepting it but masking out the host bits
before storing it.  That gives us automatic conversion if we store an
inet into a cidr if our intent is to store the network part.

What sort of bugs do you think it caused btw?

> * INET
> 
> The inet type stores the identity of an IP _host_. A host specification is
> of the form 'x.x.x.x'. Optionally, the inet type also stores the identity
> of the network the host is in. E.g., '127.0.0.5/16' means the host
> 127.0.0.5 in the network 127.0/16.

That sounds right.  We also allowed for hosts to be stored implicitely by
simply making the netmask /32.

> * Type equivalency
> 
> 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.


> * 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."  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.

-- 
D'Arcy J.M. Cain <darcy@{druid|vex}.net>   |  Democracy is three wolves
http://www.druid.net/darcy/                |  and a sheep voting on
+1 416 425 1212     (DoD#0082)    (eNTP)   |  what's for dinner.

From pgsql-hackers-owner+M4232@hub.org Tue Jul  4 22:20:30 2000
Received: from hub.org (root@hub.org [216.126.84.1])
	by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id WAA13808
	for <pgman@candle.pha.pa.us>; Tue, 4 Jul 2000 22:20:29 -0400 (EDT)
Received: from hub.org (majordom@localhost [127.0.0.1])
	by hub.org (8.10.1/8.10.1) with SMTP id e652KDS33988;
	Tue, 4 Jul 2000 22:20:13 -0400 (EDT)
Received: from druid.net (root@druid.net [216.126.72.98])
	by hub.org (8.10.1/8.10.1) with ESMTP id e652JuS33839
	for <pgsql-hackers@postgresql.org>; Tue, 4 Jul 2000 22:19:57 -0400 (EDT)
Received: from localhost (1460 bytes) by druid.net
	via sendmail with P:stdio/R:bind_hosts/T:inet_zone_bind_smtp
	(sender: <darcy>) (ident <darcy> using unix)
	id <m139emz-000AXrC@druid.net>
	for <pgsql-hackers@postgresql.org>; Tue, 4 Jul 2000 22:19:49 -0400 (EDT)
	(Smail-3.2.0.109 1999-Oct-27 #3 built 2000-Jun-28)
Message-Id: <m139emz-000AXrC@druid.net>
From: darcy@druid.net (D'Arcy J.M. Cain)
Subject: Re: [HACKERS] Repair plan for inet and cidr types
In-Reply-To: <Pine.LNX.4.21.0007050118110.3542-100000@localhost.localdomain>
	"from Peter Eisentraut at Jul 5, 2000 02:12:35 am"
To: Peter Eisentraut <peter_e@gmx.net>
Date: Tue, 4 Jul 2000 22:19:49 -0400 (EDT)
CC: PostgreSQL Development <pgsql-hackers@postgresql.org>
X-Mailer: ELM [version 2.4ME+ PL78 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII
X-Mailing-List: pgsql-hackers@postgresql.org
Precedence: bulk
Sender: pgsql-hackers-owner@hub.org
Status: OR

Thus spake Peter Eisentraut
> 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

Oh, I forgot to mention:

darcy=> select network('127.1.2.3/24'::inet);
network   
----------
127.1.2/24
(1 row)

There is also a host and netmask function and note:

darcy=> select host('127.1.2.3/24'::cidr);
ERROR:  CIDR type has no host part

But I still see no reason why that can't be implicit if we assign the
"'127.1.2.3/24'::inet" value to a cidr.  In other words let "select
('127.1.2.3/24'::inet)::cidr" give the same output.

-- 
D'Arcy J.M. Cain <darcy@{druid|vex}.net>   |  Democracy is three wolves
http://www.druid.net/darcy/                |  and a sheep voting on
+1 416 425 1212     (DoD#0082)    (eNTP)   |  what's for dinner.

From pgsql-hackers-owner+M4234@hub.org Tue Jul  4 22:31:46 2000
Received: from hub.org (root@hub.org [216.126.84.1])
	by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id WAA13855
	for <pgman@candle.pha.pa.us>; Tue, 4 Jul 2000 22:31:46 -0400 (EDT)
Received: from hub.org (majordom@localhost [127.0.0.1])
	by hub.org (8.10.1/8.10.1) with SMTP id e652VdS74063;
	Tue, 4 Jul 2000 22:31:39 -0400 (EDT)
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
	by hub.org (8.10.1/8.10.1) with ESMTP id e652VSS73985
	for <pgsql-hackers@postgresql.org>; Tue, 4 Jul 2000 22:31:28 -0400 (EDT)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
	by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id WAA29694;
	Tue, 4 Jul 2000 22:31:26 -0400 (EDT)
To: Peter Eisentraut <peter_e@gmx.net>
cc: PostgreSQL Development <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] Repair plan for inet and cidr types 
In-reply-to: <Pine.LNX.4.21.0007050118110.3542-100000@localhost.localdomain> 
References: <Pine.LNX.4.21.0007050118110.3542-100000@localhost.localdomain>
Comments: In-reply-to Peter Eisentraut <peter_e@gmx.net>
	message dated "Wed, 05 Jul 2000 02:12:35 +0200"
Date: Tue, 04 Jul 2000 22:31:25 -0400
Message-ID: <29691.962764285@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
X-Mailing-List: pgsql-hackers@postgresql.org
Precedence: bulk
Sender: pgsql-hackers-owner@hub.org
Status: OR

Peter Eisentraut <peter_e@gmx.net> writes:
> There's apparently a lack of understanding of what exactly are these types
> are supposed to do. Therefore, instead of addressing each bug
> individually, let me first state what I reconstructed as the specification
> of these types, and then add what is currently wrong with it.

This sounds good offhand, but then I never paid a whole lot of attention
to the details originally.  Did you go through the original inet/cidr
design discussions (the threads where Paul Vixie was participating)?

I don't believe Paul is subscribed here anymore, but I'd feel a lot
happier if you can contact him and get him to sign off on the clarified
design.  Maybe this is what he had in mind all along, or maybe not.

			regards, tom lane

PS: You do know who Paul Vixie is, I assume ;-).  I can think of few
better-qualified experts in this domain...

From pgsql-hackers-owner+M4312@hub.org Wed Jul  5 10:48:17 2000
Received: from hub.org (root@hub.org [216.126.84.1])
	by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id KAA02483
	for <pgman@candle.pha.pa.us>; Wed, 5 Jul 2000 10:48:16 -0400 (EDT)
Received: from hub.org (majordom@localhost [127.0.0.1])
	by hub.org (8.10.1/8.10.1) with SMTP id e65EllS08607;
	Wed, 5 Jul 2000 10:47:47 -0400 (EDT)
Received: from elektron.elka.pw.edu.pl (root@elektron.elka.pw.edu.pl [148.81.63.249])
	by hub.org (8.10.1/8.10.1) with ESMTP id e65CiPS89307
	for <pgsql-hackers@PostgreSQL.org>; Wed, 5 Jul 2000 08:44:55 -0400 (EDT)
Received: from elektron.elka.pw.edu.pl ([148.81.63.249]:41059 "EHLO
        elektron.elka.pw.edu.pl") by elektron.elka.pw.edu.pl with ESMTP
	id <S225388AbQGEMoB>; Wed, 5 Jul 2000 14:44:01 +0200
Date:   Wed, 5 Jul 2000 14:43:49 +0200 (MET DST)
From: Jakub Bartosz Bielecki <J.B.Bielecki@elka.pw.edu.pl>
To: Sevo Stille <sevo@ip23.net>
cc: Jakub Bartosz Bielecki <J.B.Bielecki@elka.pw.edu.pl>,
        pgsql-hackers@PostgreSQL.org
Subject: Re: [HACKERS] Re: postgres - development of inet/cidr
In-Reply-To: <3960A5FE.E626BAE1@ip23.net>
Message-ID: <Pine.SOL.4.21.0007051410330.1267-100000@elektron.elka.pw.edu.pl>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Mailing-List: pgsql-hackers@postgresql.org
Precedence: bulk
Sender: pgsql-hackers-owner@hub.org
Status: OR



On Mon, 3 Jul 2000, Sevo Stille wrote:
> 
> This would be proper behaviour for the cidr datatype, which describes a
> network. "select '10.0.0.1/27'::cidr='10.0.0.2/27'::cidr;" has to return
> true, as both define the same network, the mask putting the 1 vs. 2
> outside the comparison scope. 
> 
> On inet, I consider the above broken - going by the documentation,
> having a netmask on a inet datatype does not define a network address
> but rather supplies additional information on the cidr network the host
> as specified by the address is in. Accordingly, it should only truncate
> if the comparison casts to cidr. 

OK. After some inspection in list's archives I found the following
statement (http://www.postgresql.org/mhonarc/pgsql-hackers/1998-07):
> It does not work that way.  /24 is
> not a shorthand for specifying a netmask -- in CIDR, it's a "prefix
> length".
> That means "192.7.34.21/24" is either (a) a syntax error or
> (b) equivilent to "192.7.34/24".

Everybody seemed to agree with the above opinion at that time.

This is obviously _not_ the way that CIDR is handled at this moment.
"select '1.2.3.4/24'" returns "1.2.3/24" only because the _output_ routine
silently cuts host bits. Input routine stores it exactly as '1.2.3.4/24'.

Since IMHO it's wrong I prepared a patch (I'm sending it to pgsql-patch).
It fixes the CIDR input routine to zero host bits (ie beyond-prefix bits).
Please note that I didn't change the INET input routine.

Eventually I had to change a bit comparison functions.
To this moment they worked in a CIDR way (didn't compare host bits at all)
although they were used by both INET and CIDR.
Since CIDR is zero-padded now, whole 32 bits are compared by > = <
operators.
Subnet operators <<, >> are still the same, don't compare host bits.

> The big question is whether comparisons that only work on a cidr data
> type (contains/contained) or have a cidr type on one side can safely
> cast the inet type to cidr implicitly. For: 
> "select '10.0.0.1/27'::inet = '10.0.0.2/27'::inet;"  FALSE
> "select '10.0.0.1/27'::cidr = '10.0.0.2/27'::cidr;"  TRUE
> "select '10.0.0.1/27'::cidr = '10.0.0.2/27'::inet;"  FALSE
> "select '10.0.0.1/27'::cidr >> '10.0.0.2/27'::inet;" TRUE
OK.
> "select '10.0.0.1/27'::cidr << '10.0.0.2/27'::inet;" ERROR

Currently it's not an error... There is no way (and no reason) to
distinguish between INET and CIDR. Above example is exactly
equivalent to:
	select '10.0.0.0/27'::inet << '10.0.0.2/27'::inet; -- FALSE
but:
	select '10.0.0.0/27'::inet <<= '10.0.0.2/27'::inet; -- TRUE

> But we need to reach an agreement on the proper
> behaviour on greater/smaller comparisons. Should:
> 
> "select '10.0.0.1/27'::inet > '10.0.0.2/27'::cidr;"  
> 
> be true or false? Casting to cidr prior to comparison would make it
> equivalent to "select '10.0.0.0/27'::cidr > '10.0.0.0/27'::cidr;", which
> is false, both networks being equal. 

It should be (and is!) true... Since second argument is
really '10.0.0.0/27'.


From pgsql-patches-owner+M284@hub.org Wed Jul  5 09:03:39 2000
Received: from hub.org (root@hub.org [216.126.84.1])
	by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id JAA27744
	for <pgman@candle.pha.pa.us>; Wed, 5 Jul 2000 09:03:38 -0400 (EDT)
Received: from hub.org (majordom@localhost [127.0.0.1])
	by hub.org (8.10.1/8.10.1) with SMTP id e65D3OS38516;
	Wed, 5 Jul 2000 09:03:24 -0400 (EDT)
Received: from elektron.elka.pw.edu.pl (root@elektron.elka.pw.edu.pl [148.81.63.249])
	by hub.org (8.10.1/8.10.1) with ESMTP id e65Cr5S11483
	for <pgsql-patches@postgresql.org>; Wed, 5 Jul 2000 08:53:06 -0400 (EDT)
Received: from elektron.elka.pw.edu.pl ([148.81.63.249]:42221 "EHLO
        elektron.elka.pw.edu.pl") by elektron.elka.pw.edu.pl with ESMTP
	id <S225089AbQGEMwn>; Wed, 5 Jul 2000 14:52:43 +0200
Date:   Wed, 5 Jul 2000 14:52:33 +0200 (MET DST)
From: Jakub Bartosz Bielecki <J.B.Bielecki@elka.pw.edu.pl>
To: pgsql-patches@postgresql.org
Subject: [PATCHES] Re: [HACKERS] Re: postgres - development of inet/cidr
Message-ID: <Pine.SOL.4.21.0007051446090.1267-200000@elektron.elka.pw.edu.pl>
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-959030623-962801553=:1267"
X-Mailing-List: pgsql-patches@postgresql.org
Precedence: bulk
Sender: pgsql-patches-owner@hub.org
Status: OR

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.
  Send mail to mime@docserver.cac.washington.edu for more info.

---559023410-959030623-962801553=:1267
Content-Type: TEXT/PLAIN; charset=US-ASCII


1. Fixed obvious bug with strcpy() called on text type in network.c
2. Fixed CIDR input routine to cut 'host' bits in inet_net_pton.c
3. Changed network_{lt,gt,eq} to compare all bits of INET/CIDR in network.c

Jakub

---559023410-959030623-962801553=:1267
Content-Type: TEXT/PLAIN; charset=US-ASCII; name=inet-patch
Content-Transfer-Encoding: BASE64
Content-ID: <Pine.SOL.4.21.0007051452330.1267@elektron.elka.pw.edu.pl>
Content-Description: inet-patch
Content-Disposition: attachment; filename=inet-patch

KioqIC4vYmFja2VuZC91dGlscy9hZHQvaW5ldF9uZXRfcHRvbi5jLm9yaWcJ
VHVlIEp1bCAgNCAyMzowMDowNiAyMDAwDQotLS0gLi9iYWNrZW5kL3V0aWxz
L2FkdC9pbmV0X25ldF9wdG9uLmMJV2VkIEp1bCAgNSAxMToxMTozMiAyMDAw
DQoqKioqKioqKioqKioqKioNCioqKiAxMDEsMTA3ICoqKioNCiAgCQkJCXRt
cCwNCiAgCQkJCWRpcnR5LA0KICAJCQkJYml0czsNCiEgCWNvbnN0IHVfY2hh
ciAqb2RzdCA9IGRzdDsNCiAgDQogIAljaCA9ICpzcmMrKzsNCiAgCWlmIChj
aCA9PSAnMCcgJiYgKHNyY1swXSA9PSAneCcgfHwgc3JjWzBdID09ICdYJykN
Ci0tLSAxMDEsMTA3IC0tLS0NCiAgCQkJCXRtcCwNCiAgCQkJCWRpcnR5LA0K
ICAJCQkJYml0czsNCiEgCXVfY2hhciAqb2RzdCA9IGRzdDsNCiAgDQogIAlj
aCA9ICpzcmMrKzsNCiAgCWlmIChjaCA9PSAnMCcgJiYgKHNyY1swXSA9PSAn
eCcgfHwgc3JjWzBdID09ICdYJykNCioqKioqKioqKioqKioqKg0KKioqIDIx
MywyMTggKioqKg0KLS0tIDIxMywyMjYgLS0tLQ0KICAJCS8qIElmIGltcHV0
ZWQgbWFzayBpcyBuYXJyb3dlciB0aGFuIHNwZWNpZmllZCBvY3RldHMsIHdp
ZGVuLiAqLw0KICAJCWlmIChiaXRzID49IDggJiYgYml0cyA8ICgoZHN0IC0g
b2RzdCkgKiA4KSkNCiAgCQkJYml0cyA9IChkc3QgLSBvZHN0KSAqIDg7DQor
IAl9DQorIAkvKiBaZXJvIGhvc3QgYml0cyBpZiBhbnkgKi8NCisgCW4gPSBi
aXRzLzg7DQorIAlpZiggbiA8IChkc3QgLSBvZHN0KSApDQorIAl7DQorIAkJ
b2RzdFtuKytdICY9IFVDSEFSX01BWDw8KDggLSAoYml0cyAlIDgpKTsNCisg
CQlmb3IgKDtuIDwgKGRzdCAtIG9kc3QpOyBuKyspDQorIAkJCW9kc3Rbbl09
J1wwJzsNCiAgCX0NCiAgCS8qIEV4dGVuZCBuZXR3b3JrIHRvIGNvdmVyIHRo
ZSBhY3R1YWwgbWFzay4gKi8NCiAgCXdoaWxlIChiaXRzID4gKChkc3QgLSBv
ZHN0KSAqIDgpKQ0KKioqIC4vYmFja2VuZC91dGlscy9hZHQvbmV0d29yay5j
Lm9yaWcJVHVlIEp1bCAgNCAyMzowMjowMSAyMDAwDQotLS0gLi9iYWNrZW5k
L3V0aWxzL2FkdC9uZXR3b3JrLmMJVHVlIEp1bCAgNCAyMzozNToyMSAyMDAw
DQoqKioqKioqKioqKioqKioNCioqKiAxOCwyMyAqKioqDQotLS0gMTgsMjQg
LS0tLQ0KICAjaW5jbHVkZSAicG9zdGdyZXMuaCINCiAgI2luY2x1ZGUgInV0
aWxzL2J1aWx0aW5zLmgiDQogIA0KKyBzdGF0aWMgaW50CXY0Yml0Y21wKHVu
c2lnbmVkIGludCBhMSwgdW5zaWduZWQgaW50IGEyKTsNCiAgc3RhdGljIGlu
dAl2NGJpdG5jbXAodW5zaWduZWQgaW50IGExLCB1bnNpZ25lZCBpbnQgYTIs
IGludCBiaXRzKTsNCiAgDQogIC8qDQoqKioqKioqKioqKioqKioNCioqKiAx
MzcsMTQzICoqKioNCiAgCQlyZXR1cm4gRkFMU0U7DQogIAlpZiAoKGlwX2Zh
bWlseShhMSkgPT0gQUZfSU5FVCkgJiYgKGlwX2ZhbWlseShhMikgPT0gQUZf
SU5FVCkpDQogIAl7DQohIAkJaW50CQkJb3JkZXIgPSB2NGJpdG5jbXAoaXBf
djRhZGRyKGExKSwgaXBfdjRhZGRyKGEyKSwgaXBfYml0cyhhMikpOw0KICAN
CiAgCQlyZXR1cm4gKChvcmRlciA8IDApIHx8ICgob3JkZXIgPT0gMCkgJiYg
KGlwX2JpdHMoYTEpIDwgaXBfYml0cyhhMikpKSk7DQogIAl9DQotLS0gMTM4
LDE0NCAtLS0tDQogIAkJcmV0dXJuIEZBTFNFOw0KICAJaWYgKChpcF9mYW1p
bHkoYTEpID09IEFGX0lORVQpICYmIChpcF9mYW1pbHkoYTIpID09IEFGX0lO
RVQpKQ0KICAJew0KISAJCWludAkJCW9yZGVyID0gdjRiaXRjbXAoaXBfdjRh
ZGRyKGExKSwgaXBfdjRhZGRyKGEyKSk7DQogIA0KICAJCXJldHVybiAoKG9y
ZGVyIDwgMCkgfHwgKChvcmRlciA9PSAwKSAmJiAoaXBfYml0cyhhMSkgPCBp
cF9iaXRzKGEyKSkpKTsNCiAgCX0NCioqKioqKioqKioqKioqKg0KKioqIDE2
NiwxNzIgKioqKg0KICAJaWYgKChpcF9mYW1pbHkoYTEpID09IEFGX0lORVQp
ICYmIChpcF9mYW1pbHkoYTIpID09IEFGX0lORVQpKQ0KICAJew0KICAJCXJl
dHVybiAoKGlwX2JpdHMoYTEpID09IGlwX2JpdHMoYTIpKQ0KISAJCSAmJiAo
djRiaXRuY21wKGlwX3Y0YWRkcihhMSksIGlwX3Y0YWRkcihhMiksIGlwX2Jp
dHMoYTEpKSA9PSAwKSk7DQogIAl9DQogIAllbHNlDQogIAl7DQotLS0gMTY3
LDE3MyAtLS0tDQogIAlpZiAoKGlwX2ZhbWlseShhMSkgPT0gQUZfSU5FVCkg
JiYgKGlwX2ZhbWlseShhMikgPT0gQUZfSU5FVCkpDQogIAl7DQogIAkJcmV0
dXJuICgoaXBfYml0cyhhMSkgPT0gaXBfYml0cyhhMikpDQohIAkJICYmICh2
NGJpdGNtcChpcF92NGFkZHIoYTEpLCBpcF92NGFkZHIoYTIpKSA9PSAwKSk7
DQogIAl9DQogIAllbHNlDQogIAl7DQoqKioqKioqKioqKioqKioNCioqKiAx
OTIsMTk4ICoqKioNCiAgCQlyZXR1cm4gRkFMU0U7DQogIAlpZiAoKGlwX2Zh
bWlseShhMSkgPT0gQUZfSU5FVCkgJiYgKGlwX2ZhbWlseShhMikgPT0gQUZf
SU5FVCkpDQogIAl7DQohIAkJaW50CQkJb3JkZXIgPSB2NGJpdG5jbXAoaXBf
djRhZGRyKGExKSwgaXBfdjRhZGRyKGEyKSwgaXBfYml0cyhhMikpOw0KICAN
CiAgCQlyZXR1cm4gKChvcmRlciA+IDApIHx8ICgob3JkZXIgPT0gMCkgJiYg
KGlwX2JpdHMoYTEpID4gaXBfYml0cyhhMikpKSk7DQogIAl9DQotLS0gMTkz
LDE5OSAtLS0tDQogIAkJcmV0dXJuIEZBTFNFOw0KICAJaWYgKChpcF9mYW1p
bHkoYTEpID09IEFGX0lORVQpICYmIChpcF9mYW1pbHkoYTIpID09IEFGX0lO
RVQpKQ0KICAJew0KISAJCWludAkJCW9yZGVyID0gdjRiaXRjbXAoaXBfdjRh
ZGRyKGExKSwgaXBfdjRhZGRyKGEyKSk7DQogIA0KICAJCXJldHVybiAoKG9y
ZGVyID4gMCkgfHwgKChvcmRlciA9PSAwKSAmJiAoaXBfYml0cyhhMSkgPiBp
cF9iaXRzKGEyKSkpKTsNCiAgCX0NCioqKioqKioqKioqKioqKg0KKioqIDM0
MSwzNTMgKioqKg0KICANCiAgCWlmICgocHRyID0gc3RyY2hyKHRtcCwgJy8n
KSkgIT0gTlVMTCkNCiAgCQkqcHRyID0gMDsNCiEgCWxlbiA9IFZBUkhEUlNa
ICsgc3RybGVuKHRtcCkgKyAxOw0KICAJcmV0ID0gcGFsbG9jKGxlbik7DQog
IAlpZiAocmV0ID09IE5VTEwpDQogIAkJZWxvZyhFUlJPUiwgInVuYWJsZSB0
byBhbGxvY2F0ZSBtZW1vcnkgaW4gbmV0d29ya19ob3N0KCkiKTsNCiAgDQog
IAlWQVJTSVpFKHJldCkgPSBsZW47DQohIAlzdHJjcHkoVkFSREFUQShyZXQp
LCB0bXApOw0KICAJcmV0dXJuIChyZXQpOw0KICB9DQogIA0KLS0tIDM0Miwz
NTQgLS0tLQ0KICANCiAgCWlmICgocHRyID0gc3RyY2hyKHRtcCwgJy8nKSkg
IT0gTlVMTCkNCiAgCQkqcHRyID0gMDsNCiEgCWxlbiA9IFZBUkhEUlNaICsg
c3RybGVuKHRtcCk7DQogIAlyZXQgPSBwYWxsb2MobGVuKTsNCiAgCWlmIChy
ZXQgPT0gTlVMTCkNCiAgCQllbG9nKEVSUk9SLCAidW5hYmxlIHRvIGFsbG9j
YXRlIG1lbW9yeSBpbiBuZXR3b3JrX2hvc3QoKSIpOw0KICANCiAgCVZBUlNJ
WkUocmV0KSA9IGxlbjsNCiEgCW1lbWNweShWQVJEQVRBKHJldCksIHRtcCwg
bGVuLVZBUkhEUlNaKTsNCiAgCXJldHVybiAocmV0KTsNCiAgfQ0KICANCioq
KioqKioqKioqKioqKg0KKioqIDM5MSw0MDMgKioqKg0KICANCiAgCWlmICgo
cHRyID0gc3RyY2hyKHRtcCwgJy8nKSkgIT0gTlVMTCkNCiAgCQkqcHRyID0g
MDsNCiEgCWxlbiA9IFZBUkhEUlNaICsgc3RybGVuKHRtcCkgKyAxOw0KICAJ
cmV0ID0gcGFsbG9jKGxlbik7DQogIAlpZiAocmV0ID09IE5VTEwpDQogIAkJ
ZWxvZyhFUlJPUiwgInVuYWJsZSB0byBhbGxvY2F0ZSBtZW1vcnkgaW4gbmV0
d29ya19icm9hZGNhc3QoKSIpOw0KICANCiAgCVZBUlNJWkUocmV0KSA9IGxl
bjsNCiEgCXN0cmNweShWQVJEQVRBKHJldCksIHRtcCk7DQogIAlyZXR1cm4g
KHJldCk7DQogIH0NCiAgDQotLS0gMzkyLDQwNCAtLS0tDQogIA0KICAJaWYg
KChwdHIgPSBzdHJjaHIodG1wLCAnLycpKSAhPSBOVUxMKQ0KICAJCSpwdHIg
PSAwOw0KISAJbGVuID0gVkFSSERSU1ogKyBzdHJsZW4odG1wKTsNCiAgCXJl
dCA9IHBhbGxvYyhsZW4pOw0KICAJaWYgKHJldCA9PSBOVUxMKQ0KICAJCWVs
b2coRVJST1IsICJ1bmFibGUgdG8gYWxsb2NhdGUgbWVtb3J5IGluIG5ldHdv
cmtfYnJvYWRjYXN0KCkiKTsNCiAgDQogIAlWQVJTSVpFKHJldCkgPSBsZW47
DQohIAltZW1jcHkoVkFSREFUQShyZXQpLCB0bXAsIGxlbi1WQVJIRFJTWik7
DQogIAlyZXR1cm4gKHJldCk7DQogIH0NCiAgDQoqKioqKioqKioqKioqKioN
CioqKiA0MjQsNDM2ICoqKioNCiAgCQkvKiBHbyBmb3IgYW4gSVBWNiBhZGRy
ZXNzIGhlcmUsIGJlZm9yZSBmYXVsdGluZyBvdXQ6ICovDQogIAkJZWxvZyhF
UlJPUiwgInVua25vd24gYWRkcmVzcyBmYW1pbHkgKCVkKSIsIGlwX2ZhbWls
eShpcCkpOw0KICANCiEgCWxlbiA9IFZBUkhEUlNaICsgc3RybGVuKHRtcCkg
KyAxOw0KICAJcmV0ID0gcGFsbG9jKGxlbik7DQogIAlpZiAocmV0ID09IE5V
TEwpDQogIAkJZWxvZyhFUlJPUiwgInVuYWJsZSB0byBhbGxvY2F0ZSBtZW1v
cnkgaW4gbmV0d29ya19uZXR3b3JrKCkiKTsNCiAgDQogIAlWQVJTSVpFKHJl
dCkgPSBsZW47DQohIAlzdHJjcHkoVkFSREFUQShyZXQpLCB0bXApOw0KICAJ
cmV0dXJuIChyZXQpOw0KICB9DQogIA0KLS0tIDQyNSw0MzcgLS0tLQ0KICAJ
CS8qIEdvIGZvciBhbiBJUFY2IGFkZHJlc3MgaGVyZSwgYmVmb3JlIGZhdWx0
aW5nIG91dDogKi8NCiAgCQllbG9nKEVSUk9SLCAidW5rbm93biBhZGRyZXNz
IGZhbWlseSAoJWQpIiwgaXBfZmFtaWx5KGlwKSk7DQogIA0KISAJbGVuID0g
VkFSSERSU1ogKyBzdHJsZW4odG1wKTsNCiAgCXJldCA9IHBhbGxvYyhsZW4p
Ow0KICAJaWYgKHJldCA9PSBOVUxMKQ0KICAJCWVsb2coRVJST1IsICJ1bmFi
bGUgdG8gYWxsb2NhdGUgbWVtb3J5IGluIG5ldHdvcmtfbmV0d29yaygpIik7
DQogIA0KICAJVkFSU0laRShyZXQpID0gbGVuOw0KISAJbWVtY3B5KFZBUkRB
VEEocmV0KSwgdG1wLCBsZW4tVkFSSERSU1opOw0KICAJcmV0dXJuIChyZXQp
Ow0KICB9DQogIA0KKioqKioqKioqKioqKioqDQoqKiogNDYxLDQ3OSAqKioq
DQogIA0KICAJaWYgKChwdHIgPSBzdHJjaHIodG1wLCAnLycpKSAhPSBOVUxM
KQ0KICAJCSpwdHIgPSAwOw0KISAJbGVuID0gVkFSSERSU1ogKyBzdHJsZW4o
dG1wKSArIDE7DQogIAlyZXQgPSBwYWxsb2MobGVuKTsNCiAgCWlmIChyZXQg
PT0gTlVMTCkNCiAgCQllbG9nKEVSUk9SLCAidW5hYmxlIHRvIGFsbG9jYXRl
IG1lbW9yeSBpbiBuZXR3b3JrX25ldG1hc2soKSIpOw0KICANCiAgCVZBUlNJ
WkUocmV0KSA9IGxlbjsNCiEgCXN0cmNweShWQVJEQVRBKHJldCksIHRtcCk7
DQogIAlyZXR1cm4gKHJldCk7DQogIH0NCiAgDQogIC8qDQogICAqCUJpdHdp
c2UgY29tcGFyaXNvbiBmb3IgVjQgYWRkcmVzc2VzLiAgQWRkIFY2IGltcGxl
bWVudGF0aW9uIQ0KICAgKi8NCiAgDQogIHN0YXRpYyBpbnQNCiAgdjRiaXRu
Y21wKHVuc2lnbmVkIGludCBhMSwgdW5zaWduZWQgaW50IGEyLCBpbnQgYml0
cykNCi0tLSA0NjIsNDkxIC0tLS0NCiAgDQogIAlpZiAoKHB0ciA9IHN0cmNo
cih0bXAsICcvJykpICE9IE5VTEwpDQogIAkJKnB0ciA9IDA7DQohIAlsZW4g
PSBWQVJIRFJTWiArIHN0cmxlbih0bXApOw0KICAJcmV0ID0gcGFsbG9jKGxl
bik7DQogIAlpZiAocmV0ID09IE5VTEwpDQogIAkJZWxvZyhFUlJPUiwgInVu
YWJsZSB0byBhbGxvY2F0ZSBtZW1vcnkgaW4gbmV0d29ya19uZXRtYXNrKCki
KTsNCiAgDQogIAlWQVJTSVpFKHJldCkgPSBsZW47DQohIAltZW1jcHkoVkFS
REFUQShyZXQpLCB0bXAsIGxlbi1WQVJIRFJTWik7DQogIAlyZXR1cm4gKHJl
dCk7DQogIH0NCiAgDQogIC8qDQogICAqCUJpdHdpc2UgY29tcGFyaXNvbiBm
b3IgVjQgYWRkcmVzc2VzLiAgQWRkIFY2IGltcGxlbWVudGF0aW9uIQ0KICAg
Ki8NCisgDQorIHN0YXRpYyBpbnQNCisgdjRiaXRjbXAodW5zaWduZWQgaW50
IGExLCB1bnNpZ25lZCBpbnQgYTIpDQorIHsNCisgCWExID0gbnRvaGwoYTEp
Ow0KKyAJYTIgPSBudG9obChhMik7DQorIAlpZiAoYTEgPCBhMikNCisgCQly
ZXR1cm4gKC0xKTsNCisgCWVsc2UgDQorIAkJcmV0dXJuIChhMSA+IGEyKTsN
CisgfQ0KICANCiAgc3RhdGljIGludA0KICB2NGJpdG5jbXAodW5zaWduZWQg
aW50IGExLCB1bnNpZ25lZCBpbnQgYTIsIGludCBiaXRzKQ0K

---559023410-959030623-962801553=:1267--

From pgsql-hackers-owner+M4284@hub.org Wed Jul  5 09:04:09 2000
Received: from hub.org (root@hub.org [216.126.84.1])
	by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id JAA27751
	for <pgman@candle.pha.pa.us>; Wed, 5 Jul 2000 09:04:08 -0400 (EDT)
Received: from hub.org (majordom@localhost [127.0.0.1])
	by hub.org (8.10.1/8.10.1) with SMTP id e65D44S42069;
	Wed, 5 Jul 2000 09:04:04 -0400 (EDT)
Received: from turing.csis.gvsu.edu (IDENT:qmailr@csis.gvsu.edu [148.61.162.182])
	by hub.org (8.10.1/8.10.1) with SMTP id e65D2HS35607
	for <pgsql-hackers@postgresql.org>; Wed, 5 Jul 2000 09:02:17 -0400 (EDT)
Received: (qmail 4436 invoked by uid 0); 5 Jul 2000 13:02:17 -0000
Received: from eos05.csis.gvsu.edu (eisentrp@148.61.162.105)
  by turing.csis.gvsu.edu with QMQP; 5 Jul 2000 13:02:17 -0000
From: eisentrp@csis.gvsu.edu
Date: Wed, 5 Jul 2000 09:02:17 -0400 (EDT)
Reply-To: Peter Eisentraut <peter_e@gmx.net>
To: "D'Arcy J.M. Cain" <darcy@druid.net>
cc: PostgreSQL Development <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] Repair plan for inet and cidr types
In-Reply-To: <m139egU-000AXpC@druid.net>
Message-ID: <Pine.LNX.4.21.0007050842080.10677-100000@eos05.csis.gvsu.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Mailing-List: pgsql-hackers@postgresql.org
Precedence: bulk
Sender: pgsql-hackers-owner@hub.org
Status: OR

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


From pgsql-hackers-owner+M4293@hub.org Wed Jul  5 09:50:15 2000
Received: from hub.org (root@hub.org [216.126.84.1])
	by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id JAA28183
	for <pgman@candle.pha.pa.us>; Wed, 5 Jul 2000 09:50:14 -0400 (EDT)
Received: from hub.org (majordom@localhost [127.0.0.1])
	by hub.org (8.10.1/8.10.1) with SMTP id e65Do1S55862;
	Wed, 5 Jul 2000 09:50:01 -0400 (EDT)
Received: from andie.ip23.net (andie.ip23.net [212.83.32.23])
	by hub.org (8.10.1/8.10.1) with ESMTP id e65DmGS51928
	for <pgsql-hackers@PostgreSQL.org>; Wed, 5 Jul 2000 09:48:16 -0400 (EDT)
Received: from imap1.ip23.net (imap1.ip23.net [212.83.32.35])
	by andie.ip23.net (8.9.3/8.9.3) with ESMTP id PAA33008;
	Wed, 5 Jul 2000 15:48:10 +0200 (CEST)
Received: from ip23.net (spc.ip23.net [212.83.32.122])
	by imap1.ip23.net (8.9.3/8.9.3) with ESMTP id QAA00989;
	Wed, 5 Jul 2000 16:01:01 +0200 (CEST)
Message-ID: <39633C99.DD58D11F@ip23.net>
Date: Wed, 05 Jul 2000 15:48:09 +0200
From: Sevo Stille <sevo@ip23.net>
Organization: IP23
X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.10 i686)
X-Accept-Language: en, de
MIME-Version: 1.0
To: Jakub Bartosz Bielecki <J.B.Bielecki@elka.pw.edu.pl>
CC: pgsql-hackers@PostgreSQL.org
Subject: Re: [HACKERS] Re: postgres - development of inet/cidr
References: <Pine.SOL.4.21.0007051410330.1267-100000@elektron.elka.pw.edu.pl>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailing-List: pgsql-hackers@postgresql.org
Precedence: bulk
Sender: pgsql-hackers-owner@hub.org
Status: OR

Jakub Bartosz Bielecki wrote:

> > "select '10.0.0.1/27'::cidr << '10.0.0.2/27'::inet;" ERROR
> 
> Currently it's not an error... There is no way (and no reason) to
> distinguish between INET and CIDR. 

Yes, there is. CIDR is defined as the network 10.0.0.1 & /27, while INET
is defined as host 10.0.0.1 within network 10.0.0.1 & /27. You can do
almost every  network and host calculation both in CIDR and INET, but
you need implicit knowledge for it. Two columns are necessary to define
a host and its network in CIDR, and a network cannot be specified
without a host using INET - except for ugly in-band hacks like using
10.0.0.0/27 for the network which would prevent you from specifying a
base address.

> Above example is exactly
> equivalent to:
>         select '10.0.0.0/27'::inet << '10.0.0.2/27'::inet; -- FALSE

Nope. If the right hand side is automatically propagated to a network,
it is true. If not, the above IMHO should better raise an error, as a
host can never contain a host. 

> but:
>         select '10.0.0.0/27'::inet <<= '10.0.0.2/27'::inet; -- TRUE

Well, you might argue that a host could contain-or-equal a host, but as
only the equals part could ever be true, that is a redundant operator
without any meaning beyond equals, and accordingly it should not be
valid for that case.
 
> > But we need to reach an agreement on the proper
> > behaviour on greater/smaller comparisons. Should:
> >
> > "select '10.0.0.1/27'::inet > '10.0.0.2/27'::cidr;"
> >
> > be true or false? Casting to cidr prior to comparison would make it
> > equivalent to "select '10.0.0.0/27'::cidr > '10.0.0.0/27'::cidr;", which
> > is false, both networks being equal.
> 
> It should be (and is!) true... Since second argument is
> really '10.0.0.0/27'.

Yes, but that does not make it any truer. CIDR 10.0.0.0/27 is
definitively not 10.0.0.0 but [10.0.0.0 .. 10.0.0.31]. A CIDR address is
never synonymous to a plain host address. You'll see the problem if you
try to calculate the inverse - any zeroed CIDR address in the entire
range from 10.0/8 to 10.0.0.0/32 would mask to 10.0.0.0. Accordingly,
there is no simple answer to a "host bigger/smaller than network"
question. For many applications, it may be useful to define that to mean
that the host is smaller than the network bottom address respectively
bigger than the top address, but any of the other possible views would
be perfectly legal as well.
 
Sevo

-- 
sevo@ip23.net

From pgsql-hackers-owner+M4354@hub.org Wed Jul  5 16:49:21 2000
Received: from hub.org (root@hub.org [216.126.84.1])
	by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id QAA17585
	for <pgman@candle.pha.pa.us>; Wed, 5 Jul 2000 16:49:20 -0400 (EDT)
Received: from hub.org (majordom@localhost [127.0.0.1])
	by hub.org (8.10.1/8.10.1) with SMTP id e65KmdS82556;
	Wed, 5 Jul 2000 16:48:39 -0400 (EDT)
Received: from druid.net (root@druid.net [216.126.72.98])
	by hub.org (8.10.1/8.10.1) with ESMTP id e65KkqS77601
	for <pgsql-hackers@postgresql.org>; Wed, 5 Jul 2000 16:46:52 -0400 (EDT)
Received: from localhost (2500 bytes) by druid.net
	via sendmail with P:stdio/R:bind_hosts/T:inet_zone_bind_smtp
	(sender: <darcy>) (ident <darcy> using unix)
	id <m139w4G-000AXpC@druid.net>
	for <pgsql-hackers@postgresql.org>; Wed, 5 Jul 2000 16:46:48 -0400 (EDT)
	(Smail-3.2.0.109 1999-Oct-27 #3 built 2000-Jun-28)
Message-Id: <m139w4G-000AXpC@druid.net>
From: darcy@druid.net (D'Arcy J.M. Cain)
Subject: Re: [HACKERS] Repair plan for inet and cidr types
In-Reply-To: <Pine.LNX.4.21.0007050842080.10677-100000@eos05.csis.gvsu.edu>
	"from eisentrp@csis.gvsu.edu at Jul 5, 2000 09:02:17 am"
To: Peter Eisentraut <peter_e@gmx.net>
Date: Wed, 5 Jul 2000 16:46:48 -0400 (EDT)
CC: PostgreSQL Development <pgsql-hackers@postgresql.org>
X-Mailer: ELM [version 2.4ME+ PL78 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII
X-Mailing-List: pgsql-hackers@postgresql.org
Precedence: bulk
Sender: pgsql-hackers-owner@hub.org
Status: OR

Thus spake eisentrp@csis.gvsu.edu
> 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.

If it was defined well I would have no problem with it.

> > 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).

I think that's what I meant.  I'm just saying that inet::cidr should be
the same as network(inet).  Allowing that cast makes a lot of operations
work intuitively.

> 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).

Hmm.  It is a subtle difference and I did miss it.

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

I guess what I was really getting at was this.

   host OP cidr

where inet would cast to host on one side and cidr on the other.  What
we have now is 

   cidr OP cidr

with both sides casting to cidr.  Of course there is no such thing as a host
type so I don't know how we would cast such a thing.

-- 
D'Arcy J.M. Cain <darcy@{druid|vex}.net>   |  Democracy is three wolves
http://www.druid.net/darcy/                |  and a sheep voting on
+1 416 425 1212     (DoD#0082)    (eNTP)   |  what's for dinner.

From pgsql-hackers-owner+M4421@hub.org Thu Jul  6 08:54:47 2000
Received: from hub.org (root@hub.org [216.126.84.1])
	by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id IAA06169
	for <pgman@candle.pha.pa.us>; Thu, 6 Jul 2000 08:54:46 -0400 (EDT)
Received: from hub.org (majordom@localhost [127.0.0.1])
	by hub.org (8.10.1/8.10.1) with SMTP id e66CrgS44851;
	Thu, 6 Jul 2000 08:53:42 -0400 (EDT)
Received: from elektron.elka.pw.edu.pl (root@elektron.elka.pw.edu.pl [148.81.63.249])
	by hub.org (8.10.1/8.10.1) with ESMTP id e66Cr5S44024
	for <pgsql-hackers@PostgreSQL.org>; Thu, 6 Jul 2000 08:53:05 -0400 (EDT)
Received: from elektron.elka.pw.edu.pl ([148.81.63.249]:64907 "EHLO
        elektron.elka.pw.edu.pl") by elektron.elka.pw.edu.pl with ESMTP
	id <S225243AbQGFMw2>; Thu, 6 Jul 2000 14:52:28 +0200
Date:   Thu, 6 Jul 2000 14:52:17 +0200 (MET DST)
From: Jakub Bartosz Bielecki <J.B.Bielecki@elka.pw.edu.pl>
To: Sevo Stille <sevo@ip23.net>
cc: Jakub Bartosz Bielecki <J.B.Bielecki@elka.pw.edu.pl>,
        pgsql-hackers@PostgreSQL.org
Subject: Re: [HACKERS] Re: postgres - development of inet/cidr
In-Reply-To: <39633C99.DD58D11F@ip23.net>
Message-ID: <Pine.SOL.4.21.0007061354040.20142-100000@elektron.elka.pw.edu.pl>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Mailing-List: pgsql-hackers@postgresql.org
Precedence: bulk
Sender: pgsql-hackers-owner@hub.org
Status: OR



On Wed, 5 Jul 2000, Sevo Stille wrote:
> 
> > > "select '10.0.0.1/27'::cidr << '10.0.0.2/27'::inet;" ERROR
> > 
> > Currently it's not an error... There is no way (and no reason) to
> > distinguish between INET and CIDR. 
> 
> Yes, there is. CIDR is defined as the network 10.0.0.1 & /27, while INET
> is defined as host 10.0.0.1 within network 10.0.0.1 & /27. You can do
> almost every  network and host calculation both in CIDR and INET, but
> you need implicit knowledge for it.

I was talking about *current* implementation of INET/CIDR (which IMHO 
is very ill). 
There is INET for users that want simply to store IP's and don't care
about all the technical jargon.
There is CIDR for advanced users who want to store network data.

Currently these 2 types are handled by 1 implementation, moreover despite
INET netmask and CIDR prefix-length are something completely different,
both are stored in the same field of inet structure (yuck).

At the moment it works fine. But that's only a hack.
I guess the purpose was to prevent duplication of code... Blah...

> >         select '10.0.0.0/27'::inet << '10.0.0.2/27'::inet; -- FALSE
> 
> Nope. If the right hand side is automatically propagated to a network,
> it is true. If not, the above IMHO should better raise an error, as a
> host can never contain a host. 
> 
> >         select '10.0.0.0/27'::inet <<= '10.0.0.2/27'::inet; -- TRUE
> 
> Well, you might argue that a host could contain-or-equal a host, but as
> only the equals part could ever be true, that is a redundant operator
> without any meaning beyond equals, and accordingly it should not be
> valid for that case.
>  
> > > "select '10.0.0.1/27'::inet > '10.0.0.2/27'::cidr;"
> > It should be (and is!) true... Since second argument is
> > really '10.0.0.0/27'.
> 
> Yes, but that does not make it any truer. CIDR 10.0.0.0/27 is
> definitively not 10.0.0.0 but [10.0.0.0 .. 10.0.0.31].

Same as above... You are perfectly right.

Everything works until user starts messing with _both_ INET and CIDR
at the same time.

The possible solution is:
- inhibit cidr-to-inet cast (and maybe also inet-to-cidr, because
  it would throw away netmask),
- CIDR operators: > = < << >>
- INET operators: > = <  (and why not & | if it would be useful???)
       functions:	cidr network(inet); 	// '10.0.0.0/27'
			text host(inet); 	// '10.0.0.1'
			int masklen(inet); 	// 27
- write an usable manual.

Comments?
I *might* work on it if I find some spare time. But it's unlikely :(


From pgsql-hackers-owner+M4503@hub.org Fri Jul  7 12:11:37 2000
Received: from hub.org (root@hub.org [216.126.84.1])
	by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id MAA26802
	for <pgman@candle.pha.pa.us>; Fri, 7 Jul 2000 12:11:36 -0400 (EDT)
Received: from hub.org (majordom@localhost [127.0.0.1])
	by hub.org (8.10.1/8.10.1) with SMTP id e67GAgW67823;
	Fri, 7 Jul 2000 12:10:42 -0400 (EDT)
Received: from merganser.its.uu.se (merganser.its.uu.se [130.238.6.236])
	by hub.org (8.10.1/8.10.1) with ESMTP id e67G9qW66262
	for <pgsql-hackers@postgresql.org>; Fri, 7 Jul 2000 12:09:52 -0400 (EDT)
Received: from regulus.student.UU.SE ([130.238.5.2]:53522 "EHLO
        regulus.its.uu.se") by merganser.its.uu.se with ESMTP
	id <S493726AbQGGQJO>; Fri, 7 Jul 2000 18:09:14 +0200
Received: from peter (helo=localhost)
	by regulus.its.uu.se with local-esmtp (Exim 3.02 #2)
	id 13Aani-0003A6-00; Fri, 07 Jul 2000 18:16:26 +0200
Date:   Fri, 7 Jul 2000 18:16:26 +0200 (CEST)
From: Peter Eisentraut <peter_e@gmx.net>
To: "D'Arcy J.M. Cain" <darcy@druid.net>
cc: PostgreSQL Development <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] Repair plan for inet and cidr types
In-Reply-To: <m139w4G-000AXpC@druid.net>
Message-ID: <Pine.LNX.4.21.0007070156410.4191-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
X-Mailing-List: pgsql-hackers@postgresql.org
Precedence: bulk
Sender: pgsql-hackers-owner@hub.org
Status: OR

D'Arcy J.M. Cain writes:

> > 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.
> 
> If it was defined well I would have no problem with it.

That is certainly not how type systems operate anywhere.

> I guess what I was really getting at was this.
> 
>    host OP cidr
> 
> where inet would cast to host on one side and cidr on the other.  What
> we have now is 
> 
>    cidr OP cidr
> 
> with both sides casting to cidr.  Of course there is no such thing as a host
> type so I don't know how we would cast such a thing.

I think that while the implicit casting could sometimes be convenient,
it's also a source of confusion. Consider the statement

select '10.0.0.3'::cidr < '10.0.0.2'::inet;	=> f

This cannot possibly make sense on closer inspection. Firstly, it's
semantic nonsense, you cannot order a network and a host. Secondly, it's
also wrong. According to the documentation, the '10.0.0.3'::cidr should be
converted to '10/8' internally. Then one of two things could have happened
here: 1) cidr was implicitly converted to inet and '10.0.0.3' is taken to
be a host, which is completely wrong. Or 2) inet was converted to cidr.
But then we're looking at '10/8' < '10.0.0.2/32', which should be true.

See also

select '10.0.0.2'::cidr = '10.0.0.2'::inet;	=> t

which is wrong for similar reasons.


Then let's look at the << family of operators.

select '10.0.0.2'::cidr >> '10.0.0.2'::inet;	=> f

Again, there are two ways this could currently be resolved:

	'10/8'::cidr >> '10.0.0.2/32'::cidr	which does return true
or
	'10.0.0.2'::inet >> '10.0.0.2'::inet
which doesn't make any sense.

On closer inspection, the inet << cidr case is completely misbehaving: