path: root/doc/TODO.detail/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:

select '10.0.0.5/8'::inet << '10.0.0.0/16'::cidr;	=> f
select '10.0.0.5/24'::inet << '10.0.0.0/16'::cidr;	=> t

This is not what I'd expect.

Concretely, the cases
	inet << cidr
	cidr << cidr
are not the same:

	'10.0.0.5/8'::inet << '10.0.0.0/16'::cidr
should be true

	'10.0.0.5/8'::cidr << '10.0.0.0/16'::cidr
should be false, if you allow the left-side value in at all, which I
wouldn't.

What this tells me is that the cast from inet to cidr is not well-defined
in the mathematical sense, and therefore no implicit casting should be
allowed.

So the bottom line here is that these two types are, while from a related
domain, different, and the user should be the one that controls when and
how they are mixed together.


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


From pgsql-hackers-owner+M5242@hub.org Sun Jul 23 10:01:45 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 KAA21261
	for <pgman@candle.pha.pa.us>; Sun, 23 Jul 2000 10:01:44 -0400 (EDT)
Received: from hub.org (majordom@localhost [127.0.0.1])
	by hub.org (8.10.1/8.10.1) with SMTP id e6NE1Th91342;
	Sun, 23 Jul 2000 10:01:29 -0400 (EDT)
Received: from lerami.lerctr.org (lerami.lerctr.org [207.158.72.11])
	by hub.org (8.10.1/8.10.1) with ESMTP id e6NE10h91172
	for <pgsql-hackers@hub.org>; Sun, 23 Jul 2000 10:01:00 -0400 (EDT)
Received: (from ler@localhost)
	by lerami.lerctr.org (8.10.1/8.10.1/20000715) id e6NE0w219946
	for pgsql-hackers@hub.org; Sun, 23 Jul 2000 09:00:58 -0500 (CDT)
From: Larry Rosenman <ler@lerctr.org>
Message-Id: <200007231400.e6NE0w219946@lerami.lerctr.org>
Subject: [HACKERS] INET/CIDR types
To: pgsql-hackers@hub.org
Date: Sun, 23 Jul 2000 09:00:57 -0500 (CDT)
X-Mailer: ELM [version 2.4ME+ PL79 (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

I noticed a discussion on this list about a re-do of the INET/CIDR
types.   I was wondering if there was ANY way at all to add
an output function that ALWAYS returns all 4 octets of an INET or CIDR
type with and without the /netmask?

I'm writing a IP Allocation/Tracking app for the ISP I work for, and
find the current output format causes confusion for the less
technical types. 

Larry Rosenman
-- 
Larry Rosenman                      http://www.lerctr.org/~ler
Phone: +1 972-414-9812 (voice) Internet: ler@lerctr.org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749

From pgsql-hackers-owner+M5264@hub.org Mon Jul 24 10:34: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 KAA09676
	for <pgman@candle.pha.pa.us>; Mon, 24 Jul 2000 10:34: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 e6OEXZh83378;
	Mon, 24 Jul 2000 10:33:35 -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 e6OEXGh83201
	for <pgsql-hackers@hub.org>; Mon, 24 Jul 2000 10:33:16 -0400 (EDT)
Received: from localhost (1444 bytes) by druid.net
	via sendmail with P:stdio/R:bind_hosts/T:inet_zone_bind_smtp
	(sender: <darcy>) (ident <darcy> using unix)
	id <m13GjIB-000AXgC@druid.net>
	for <pgsql-hackers@hub.org>; Mon, 24 Jul 2000 10:33:15 -0400 (EDT)
	(Smail-3.2.0.109 1999-Oct-27 #3 built 2000-Jun-28)
Message-Id: <m13GjIB-000AXgC@druid.net>
From: darcy@druid.net (D'Arcy J.M. Cain)
Subject: Re: [HACKERS] INET/CIDR types
In-Reply-To: <200007231400.e6NE0w219946@lerami.lerctr.org> "from Larry Rosenman
	at Jul 23, 2000 09:00:57 am"
To: Larry Rosenman <ler@lerctr.org>
Date: Mon, 24 Jul 2000 10:33:14 -0400 (EDT)
CC: pgsql-hackers@hub.org
Reply-To: pgsql-hackers@hub.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 Larry Rosenman
> I noticed a discussion on this list about a re-do of the INET/CIDR
> types.   I was wondering if there was ANY way at all to add
> an output function that ALWAYS returns all 4 octets of an INET or CIDR
> type with and without the /netmask?
> 
> I'm writing a IP Allocation/Tracking app for the ISP I work for, and
> find the current output format causes confusion for the less
> technical types. 

The host() function does this for the INET type.  It doesn't work for
the CIDR type (it throws an error) because CIDR doesn't have a host
part per se.

darcy=> select '1.2.0.0/23'::inet;
?column?
--------
1.2.0/23
(1 row)

darcy=> select host('1.2.0.0/23'::inet);
   host
-------
1.2.0.0
(1 row)

-- 
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+M5265@hub.org Mon Jul 24 10:43:14 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 KAA09722
	for <pgman@candle.pha.pa.us>; Mon, 24 Jul 2000 10:43:13 -0400 (EDT)
Received: from hub.org (majordom@localhost [127.0.0.1])
	by hub.org (8.10.1/8.10.1) with SMTP id e6OEfLh86364;
	Mon, 24 Jul 2000 10:41:21 -0400 (EDT)
Received: from lerami.lerctr.org (lerami.lerctr.org [207.158.72.11])
	by hub.org (8.10.1/8.10.1) with ESMTP id e6OEf6h86190
	for <pgsql-hackers@hub.org>; Mon, 24 Jul 2000 10:41:06 -0400 (EDT)
Received: (from ler@localhost)
	by lerami.lerctr.org (8.10.1/8.10.1/20000715) id e6OEf5D12433;
	Mon, 24 Jul 2000 09:41:05 -0500 (CDT)
From: Larry Rosenman <ler@lerctr.org>
Message-Id: <200007241441.e6OEf5D12433@lerami.lerctr.org>
Subject: Re: [HACKERS] INET/CIDR types
In-Reply-To: <m13GjIB-000AXgC@druid.net> "from darcy@druid.net at Jul 24, 2000
	10:33:14 am"
To: pgsql-hackers@hub.org
Date: Mon, 24 Jul 2000 09:41:05 -0500 (CDT)
CC: Larry Rosenman <ler@lerctr.org>
X-Mailer: ELM [version 2.4ME+ PL79 (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

The bad news is that I'm tracking CIDR blocks. 

If I could get a network() function to return essentially
host()::inet for CIDR's that would work. 

Larry
> Thus spake Larry Rosenman
> > I noticed a discussion on this list about a re-do of the INET/CIDR
> > types.   I was wondering if there was ANY way at all to add
> > an output function that ALWAYS returns all 4 octets of an INET or CIDR
> > type with and without the /netmask?
> > 
> > I'm writing a IP Allocation/Tracking app for the ISP I work for, and
> > find the current output format causes confusion for the less
> > technical types. 
> 
> The host() function does this for the INET type.  It doesn't work for
> the CIDR type (it throws an error) because CIDR doesn't have a host
> part per se.
> 
> darcy=> select '1.2.0.0/23'::inet;
> ?column?
> --------
> 1.2.0/23
> (1 row)
> 
> darcy=> select host('1.2.0.0/23'::inet);
>    host
> -------
> 1.2.0.0
> (1 row)
> 
> -- 
> 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.


-- 
Larry Rosenman                      http://www.lerctr.org/~ler
Phone: +1 972-414-9812 (voice) Internet: ler@lerctr.org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749

From pgsql-hackers-owner+M5270@hub.org Mon Jul 24 15:17: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 PAA11467
	for <pgman@candle.pha.pa.us>; Mon, 24 Jul 2000 15:17: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 e6OJHEh72992;
	Mon, 24 Jul 2000 15:17:14 -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 e6OJF3h71969
	for <pgsql-hackers@hub.org>; Mon, 24 Jul 2000 15:15:04 -0400 (EDT)
Received: from localhost (1687 bytes) by druid.net
	via sendmail with P:stdio/R:bind_hosts/T:inet_zone_bind_smtp
	(sender: <darcy>) (ident <darcy> using unix)
	id <m13Gngs-000AXeC@druid.net>
	for <pgsql-hackers@hub.org>; Mon, 24 Jul 2000 15:15:02 -0400 (EDT)
	(Smail-3.2.0.109 1999-Oct-27 #3 built 2000-Jun-28)
Message-Id: <m13Gngs-000AXeC@druid.net>
From: darcy@druid.net (D'Arcy J.M. Cain)
Subject: Re: [HACKERS] INET/CIDR types
In-Reply-To: <200007241441.e6OEf5D12433@lerami.lerctr.org> "from Larry Rosenman
	at Jul 24, 2000 09:41:05 am"
To: Larry Rosenman <ler@lerctr.org>
Date: Mon, 24 Jul 2000 15:15:01 -0400 (EDT)
CC: pgsql-hackers@hub.org
Reply-To: pgsql-hackers@hub.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 Larry Rosenman
> The bad news is that I'm tracking CIDR blocks. 

Then there is no host part.  I would argue that if someone is getting
confused with the current output then perhaps they shouldn't be dealing
with client networks.

> If I could get a network() function to return essentially
> host()::inet for CIDR's that would work. 

There is a network function.  It returns the network.

darcy=> select network('1.2.0.0/23'::cidr);
network 
--------
1.2.0/23
(1 row)

A lot of work went into these types to make them correct.  I don't think
we should be undermining that to allow people to work with incorrect
assumptions.  If you want Micro$oft you know where to find it.

If you really must do this then store your blocks in the INET type.  It
pretty much does what you want but doesn't try to pretend to be a CIDR.


Hmmm.  I just noticed this.

darcy=> select '1.2.0.1/23'::cidr;
?column?
--------
1.2.0/23
(1 row)

Shouldn't that throw an error?

-- 
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+M5271@hub.org Mon Jul 24 15:28: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 PAA11521
	for <pgman@candle.pha.pa.us>; Mon, 24 Jul 2000 15:28: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 e6OJSMh77820;
	Mon, 24 Jul 2000 15:28:22 -0400 (EDT)
Received: from lerami.lerctr.org (lerami.lerctr.org [207.158.72.11])
	by hub.org (8.10.1/8.10.1) with ESMTP id e6OJQhh76867
	for <pgsql-hackers@hub.org>; Mon, 24 Jul 2000 15:26:43 -0400 (EDT)
Received: from lerdesk (ler-desk.iadfw.net [206.66.13.18])
	by lerami.lerctr.org (8.10.1/8.10.1/20000715) with SMTP id e6OJQcc24312;
	Mon, 24 Jul 2000 14:26:38 -0500 (CDT)
From: "Larry Rosenman" <ler@lerctr.org>
To: <pgsql-hackers@hub.org>, "Larry Rosenman" <ler@lerctr.org>
Subject: RE: [HACKERS] INET/CIDR types
Date: Mon, 24 Jul 2000 14:26:37 -0500
Message-ID: <NCBBKBDOOHHEJCJHLLPAMELAHIAA.ler@lerctr.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
In-Reply-To: <m13Gngs-000AXeC@druid.net>
X-Mailing-List: pgsql-hackers@postgresql.org
Precedence: bulk
Sender: pgsql-hackers-owner@hub.org
Status: OR

The problem is NON-TECHNICAL people will be getting the output,
and they expect 4 octet output. 

I really think that we should have a way to coerce a CIDR to
an INET, and then allow host(). 

Remember that I am dealing with $10/hour clerks. 

I really don't get the hostility to changing the OUTPUT format...

Larry Rosenman

-----Original Message-----
From: D'Arcy J.M. Cain [mailto:darcy@druid.net]
Sent: Monday, July 24, 2000 2:15 PM
To: Larry Rosenman
Cc: pgsql-hackers@hub.org
Subject: Re: [HACKERS] INET/CIDR types


Thus spake Larry Rosenman
> The bad news is that I'm tracking CIDR blocks. 

Then there is no host part.  I would argue that if someone is getting
confused with the current output then perhaps they shouldn't be dealing
with client networks.

> If I could get a network() function to return essentially
> host()::inet for CIDR's that would work. 

There is a network function.  It returns the network.

darcy=> select network('1.2.0.0/23'::cidr);
network 
--------
1.2.0/23
(1 row)

A lot of work went into these types to make them correct.  I don't think
we should be undermining that to allow people to work with incorrect
assumptions.  If you want Micro$oft you know where to find it.

If you really must do this then store your blocks in the INET type.  It
pretty much does what you want but doesn't try to pretend to be a CIDR.


Hmmm.  I just noticed this.

darcy=> select '1.2.0.1/23'::cidr;
?column?
--------
1.2.0/23
(1 row)

Shouldn't that throw an error?

-- 
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+M5272@hub.org Mon Jul 24 15:35:28 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 PAA11554
	for <pgman@candle.pha.pa.us>; Mon, 24 Jul 2000 15:35:28 -0400 (EDT)
Received: from hub.org (majordom@localhost [127.0.0.1])
	by hub.org (8.10.1/8.10.1) with SMTP id e6OJZFh80569;
	Mon, 24 Jul 2000 15:35:16 -0400 (EDT)
Received: from smtp.pacifier.com (comet.pacifier.com [199.2.117.155])
	by hub.org (8.10.1/8.10.1) with ESMTP id e6OJXgh80113
	for <pgsql-hackers@hub.org>; Mon, 24 Jul 2000 15:33:42 -0400 (EDT)
Received: from desktop (dsl-dhogaza.pacifier.net [207.202.226.68])
	by smtp.pacifier.com (8.9.3/8.9.3pop) with SMTP id MAA07579;
	Mon, 24 Jul 2000 12:33:32 -0700 (PDT)
Message-Id: <3.0.1.32.20000724123008.01189db0@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Mon, 24 Jul 2000 12:30:08 -0700
To: "Larry Rosenman" <ler@lerctr.org>, <pgsql-hackers@hub.org>,
        "Larry Rosenman" <ler@lerctr.org>
From: Don Baccus <dhogaza@pacifier.com>
Subject: RE: [HACKERS] INET/CIDR types
In-Reply-To: <NCBBKBDOOHHEJCJHLLPAMELAHIAA.ler@lerctr.org>
References: <m13Gngs-000AXeC@druid.net>
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

At 02:26 PM 7/24/00 -0500, Larry Rosenman wrote:
>The problem is NON-TECHNICAL people will be getting the output,
>and they expect 4 octet output. 
>
>I really think that we should have a way to coerce a CIDR to
>an INET, and then allow host(). 
>
>Remember that I am dealing with $10/hour clerks. 
>
>I really don't get the hostility to changing the OUTPUT format...

Are these $10/hour clerks typing in SQL to psql?  Strange ...

If not, formatting issues like this can easily be broken (or fixed,
according to your POV) by your application client.



- Don Baccus, Portland OR <dhogaza@pacifier.com>
  Nature photos, on-line guides, Pacific Northwest
  Rare Bird Alert Service and other goodies at
  http://donb.photo.net.

From pgsql-hackers-owner+M5273@hub.org Mon Jul 24 15:38: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 PAA11571
	for <pgman@candle.pha.pa.us>; Mon, 24 Jul 2000 15:38:45 -0400 (EDT)
Received: from hub.org (majordom@localhost [127.0.0.1])
	by hub.org (8.10.1/8.10.1) with SMTP id e6OJcPh81593;
	Mon, 24 Jul 2000 15:38:25 -0400 (EDT)
Received: from lerami.lerctr.org (lerami.lerctr.org [207.158.72.11])
	by hub.org (8.10.1/8.10.1) with ESMTP id e6OJanh80997
	for <pgsql-hackers@hub.org>; Mon, 24 Jul 2000 15:36:49 -0400 (EDT)
Received: from lerdesk (ler-desk.iadfw.net [206.66.13.18])
	by lerami.lerctr.org (8.10.1/8.10.1/20000715) with SMTP id e6OJajc24698;
	Mon, 24 Jul 2000 14:36:45 -0500 (CDT)
From: "Larry Rosenman" <ler@lerctr.org>
To: "Don Baccus" <dhogaza@pacifier.com>, "Larry Rosenman" <ler@lerctr.org>,
        <pgsql-hackers@hub.org>, "Larry Rosenman" <ler@lerctr.org>
Subject: RE: [HACKERS] INET/CIDR types
Date: Mon, 24 Jul 2000 14:36:44 -0500
Message-ID: <NCBBKBDOOHHEJCJHLLPACELCHIAA.ler@lerctr.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
In-Reply-To: <3.0.1.32.20000724123008.01189db0@mail.pacifier.com>
X-Mailing-List: pgsql-hackers@postgresql.org
Precedence: bulk
Sender: pgsql-hackers-owner@hub.org
Status: OR

I was hoping to have some niceties out of the SQL retrieve to print directly
in PHP, and not have to massage it. 

Why is there such animosity to printing out all 4 octets in some function
somewhere for a CIDR block?

Larry 

-----Original Message-----
From: Don Baccus [mailto:dhogaza@pacifier.com]
Sent: Monday, July 24, 2000 2:30 PM
To: Larry Rosenman; pgsql-hackers@hub.org; Larry Rosenman
Subject: RE: [HACKERS] INET/CIDR types


At 02:26 PM 7/24/00 -0500, Larry Rosenman wrote:
>The problem is NON-TECHNICAL people will be getting the output,
>and they expect 4 octet output. 
>
>I really think that we should have a way to coerce a CIDR to
>an INET, and then allow host(). 
>
>Remember that I am dealing with $10/hour clerks. 
>
>I really don't get the hostility to changing the OUTPUT format...

Are these $10/hour clerks typing in SQL to psql?  Strange ...

If not, formatting issues like this can easily be broken (or fixed,
according to your POV) by your application client.



- Don Baccus, Portland OR <dhogaza@pacifier.com>
  Nature photos, on-line guides, Pacific Northwest
  Rare Bird Alert Service and other goodies at
  http://donb.photo.net.

From pgsql-hackers-owner+M5274@hub.org Mon Jul 24 16:19: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 QAA11771
	for <pgman@candle.pha.pa.us>; Mon, 24 Jul 2000 16:19: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 e6OKJRh99659;
	Mon, 24 Jul 2000 16:19: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 e6OKHbh98841
	for <pgsql-hackers@hub.org>; Mon, 24 Jul 2000 16:17:37 -0400 (EDT)
Received: from localhost (1546 bytes) by druid.net
	via sendmail with P:stdio/R:bind_hosts/T:inet_zone_bind_smtp
	(sender: <darcy>) (ident <darcy> using unix)
	id <m13GofQ-000AX1C@druid.net>
	for <pgsql-hackers@hub.org>; Mon, 24 Jul 2000 16:17:36 -0400 (EDT)
	(Smail-3.2.0.109 1999-Oct-27 #3 built 2000-Jun-28)
Message-Id: <m13GofQ-000AX1C@druid.net>
From: darcy@druid.net (D'Arcy J.M. Cain)
Subject: Re: [HACKERS] INET/CIDR types
In-Reply-To: <NCBBKBDOOHHEJCJHLLPACELCHIAA.ler@lerctr.org> "from Larry Rosenman
	at Jul 24, 2000 02:36:44 pm"
To: Larry Rosenman <ler@lerctr.org>
Date: Mon, 24 Jul 2000 16:17:36 -0400 (EDT)
CC: Don Baccus <dhogaza@pacifier.com>, pgsql-hackers@hub.org
Reply-To: pgsql-hackers@hub.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 Larry Rosenman
> I was hoping to have some niceties out of the SQL retrieve to print directly
> in PHP, and not have to massage it. 
> 
> Why is there such animosity to printing out all 4 octets in some function
> somewhere for a CIDR block?

You keep saying "hostility" as if we are ganging up against you.  Believe
me, I have no animosity towards you and I am sure no one else has either.
We are resisting the change you want simply because it would violate the
RFC which we agreed to follow when we created the types.

If you think this is hostile, you will probably think that the original
discussions in the archives are nuclear war :-).  If you would like to
look it over make sure to set aside a lot of time.  We spent a long time
hashing this out.

-- 
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+M5275@hub.org Mon Jul 24 16:29: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 QAA11819
	for <pgman@candle.pha.pa.us>; Mon, 24 Jul 2000 16:29:28 -0400 (EDT)
Received: from hub.org (majordom@localhost [127.0.0.1])
	by hub.org (8.10.1/8.10.1) with SMTP id e6OKT6h02534;
	Mon, 24 Jul 2000 16:29:06 -0400 (EDT)
Received: from lerami.lerctr.org (lerami.lerctr.org [207.158.72.11])
	by hub.org (8.10.1/8.10.1) with ESMTP id e6OKRUh02012
	for <pgsql-hackers@hub.org>; Mon, 24 Jul 2000 16:27:30 -0400 (EDT)
Received: from lerdesk (ler-desk.iadfw.net [206.66.13.18])
	by lerami.lerctr.org (8.10.1/8.10.1/20000715) with SMTP id e6OKRPc26861;
	Mon, 24 Jul 2000 15:27:25 -0500 (CDT)
From: "Larry Rosenman" <ler@lerctr.org>
To: <pgsql-hackers@hub.org>, "Larry Rosenman" <ler@lerctr.org>
Cc: "Don Baccus" <dhogaza@pacifier.com>
Subject: RE: [HACKERS] INET/CIDR types
Date: Mon, 24 Jul 2000 15:27:24 -0500
Message-ID: <NCBBKBDOOHHEJCJHLLPAAELHHIAA.ler@lerctr.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
In-Reply-To: <m13GofQ-000AX1C@druid.net>
X-Mailing-List: pgsql-hackers@postgresql.org
Precedence: bulk
Sender: pgsql-hackers-owner@hub.org
Status: OR

What RFC says you can't print all 4 octets of a CIDR Netnumber?

Why does network(cidr) return the whole cidr output just like
select cidr?

I'm just trying to figure out the logic here.

Here is what my Cisco Router that speaks BGP says:
big-bro#term ip netmask-format bit-count
big-bro#sh ip bg 206.66.0.0/20
BGP routing table entry for 206.66.0.0/20, version 150832
Paths: (5 available, best #4)
  Advertised to non peer-group peers:
    157.130.140.109 166.63.135.33 206.66.12.3 206.66.12.4 206.66.12.7
206.66.12.
8
  Local, (aggregated by 4278 206.66.12.3), (received & used)
    206.66.12.3 from 206.66.12.3 (206.66.12.3)
      Origin IGP, localpref 0, valid, internal, atomic-aggregate
  Local, (aggregated by 4278 206.66.12.7), (received & used)
    206.66.12.7 from 206.66.12.7 (206.66.12.7)
      Origin IGP, localpref 0, valid, internal, atomic-aggregate
  Local, (aggregated by 4278 206.66.12.8), (received & used)
    206.66.12.8 from 206.66.12.8 (206.66.12.8)
      Origin IGP, localpref 0, valid, internal, atomic-aggregate
  Local, (aggregated by 4278 206.66.12.1)
    0.0.0.0 from 0.0.0.0 (206.66.12.1)
      Origin IGP, localpref 100, weight 32768, valid, aggregated, local,
atomic-
aggregate, best
  Local, (received & used)
    206.66.12.4 from 206.66.12.4 (206.66.12.4)
      Origin IGP, metric 0, localpref 100, valid, internal
big-bro#

I am just asking for the same type output.

Why is this so hard?

The info is in the type, and the print routine wouldn't be so hard.

I can probably write the function in less than 1 hour, but getting it
integrated is
my stumbling block.



-----Original Message-----
From: D'Arcy J.M. Cain [mailto:darcy@druid.net]
Sent: Monday, July 24, 2000 3:18 PM
To: Larry Rosenman
Cc: Don Baccus; pgsql-hackers@hub.org
Subject: Re: [HACKERS] INET/CIDR types


Thus spake Larry Rosenman
> I was hoping to have some niceties out of the SQL retrieve to print
directly
> in PHP, and not have to massage it.
>
> Why is there such animosity to printing out all 4 octets in some function
> somewhere for a CIDR block?

You keep saying "hostility" as if we are ganging up against you.  Believe
me, I have no animosity towards you and I am sure no one else has either.
We are resisting the change you want simply because it would violate the
RFC which we agreed to follow when we created the types.

If you think this is hostile, you will probably think that the original
discussions in the archives are nuclear war :-).  If you would like to
look it over make sure to set aside a lot of time.  We spent a long time
hashing this out.

--
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+M5276@hub.org Mon Jul 24 16:54:14 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 QAA11929
	for <pgman@candle.pha.pa.us>; Mon, 24 Jul 2000 16:54:13 -0400 (EDT)
Received: from hub.org (majordom@localhost [127.0.0.1])
	by hub.org (8.10.1/8.10.1) with SMTP id e6OKruh24719;
	Mon, 24 Jul 2000 16:53:56 -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 e6OKrPh24294
	for <pgsql-hackers@hub.org>; Mon, 24 Jul 2000 16:53:25 -0400 (EDT)
Received: from localhost (1495 bytes) by druid.net
	via sendmail with P:stdio/R:bind_hosts/T:inet_zone_bind_smtp
	(sender: <darcy>) (ident <darcy> using unix)
	id <m13GpE4-000AX0C@druid.net>
	for <pgsql-hackers@hub.org>; Mon, 24 Jul 2000 16:53:24 -0400 (EDT)
	(Smail-3.2.0.109 1999-Oct-27 #3 built 2000-Jun-28)
Message-Id: <m13GpE4-000AX0C@druid.net>
From: darcy@druid.net (D'Arcy J.M. Cain)
Subject: Re: [HACKERS] INET/CIDR types
In-Reply-To: <NCBBKBDOOHHEJCJHLLPAAELHHIAA.ler@lerctr.org> "from Larry Rosenman
	at Jul 24, 2000 03:27:24 pm"
To: Larry Rosenman <ler@lerctr.org>
Date: Mon, 24 Jul 2000 16:53:24 -0400 (EDT)
CC: pgsql-hackers@hub.org, Don Baccus <dhogaza@pacifier.com>
Reply-To: pgsql-hackers@hub.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 Larry Rosenman
> What RFC says you can't print all 4 octets of a CIDR Netnumber?

Can't recall.  It was Paul Vixie who made the claim and since he was
probably the one who wrote it I tend to believe him.

In fact it may be that it suggested rather than required but someone
would have to dig out the RFC before we considered changing it I think.

> Why does network(cidr) return the whole cidr output just like
> select cidr?

Yah, it's redundant.  "network(cidr)" is just a long way to say "cidr."
The only reason it is there is because of the way the code was written
for the two types.  Not having it would have required a special test to
look for it and technically it is correct so we didn't bother.

-- 
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+M5277@hub.org Mon Jul 24 17:12:12 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 RAA12251
	for <pgman@candle.pha.pa.us>; Mon, 24 Jul 2000 17:12:11 -0400 (EDT)
Received: from hub.org (majordom@localhost [127.0.0.1])
	by hub.org (8.10.1/8.10.1) with SMTP id e6OLBth32813;
	Mon, 24 Jul 2000 17:11:55 -0400 (EDT)
Received: from lerami.lerctr.org (lerami.lerctr.org [207.158.72.11])
	by hub.org (8.10.1/8.10.1) with ESMTP id e6OLBah32716
	for <pgsql-hackers@hub.org>; Mon, 24 Jul 2000 17:11:36 -0400 (EDT)
Received: from lerdesk (ler-desk.iadfw.net [206.66.13.18])
	by lerami.lerctr.org (8.10.1/8.10.1/20000715) with SMTP id e6OLBZc28924;
	Mon, 24 Jul 2000 16:11:35 -0500 (CDT)
From: "Larry Rosenman" <ler@lerctr.org>
To: <pgsql-hackers@hub.org>, "Larry Rosenman" <ler@lerctr.org>
Cc: "Don Baccus" <dhogaza@pacifier.com>
Subject: RE: [HACKERS] INET/CIDR types
Date: Mon, 24 Jul 2000 16:11:34 -0500
Message-ID: <NCBBKBDOOHHEJCJHLLPAIELMHIAA.ler@lerctr.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
In-Reply-To: <m13GpE4-000AX0C@druid.net>
X-Mailing-List: pgsql-hackers@postgresql.org
Precedence: bulk
Sender: pgsql-hackers-owner@hub.org
Status: OR

Can we dig up the RFC?

Larry

-----Original Message-----
From: pgsql-hackers-owner@hub.org [mailto:pgsql-hackers-owner@hub.org]On
Behalf Of D'Arcy J.M. Cain
Sent: Monday, July 24, 2000 3:53 PM
To: Larry Rosenman
Cc: pgsql-hackers@hub.org; Don Baccus
Subject: Re: [HACKERS] INET/CIDR types


Thus spake Larry Rosenman
> What RFC says you can't print all 4 octets of a CIDR Netnumber?

Can't recall.  It was Paul Vixie who made the claim and since he was
probably the one who wrote it I tend to believe him.

In fact it may be that it suggested rather than required but someone
would have to dig out the RFC before we considered changing it I think.

> Why does network(cidr) return the whole cidr output just like
> select cidr?

Yah, it's redundant.  "network(cidr)" is just a long way to say "cidr."
The only reason it is there is because of the way the code was written
for the two types.  Not having it would have required a special test to
look for it and technically it is correct so we didn't bother.

-- 
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+M5278@hub.org Mon Jul 24 18:31:03 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 SAA12804
	for <pgman@candle.pha.pa.us>; Mon, 24 Jul 2000 18:31:03 -0400 (EDT)
Received: from hub.org (majordom@localhost [127.0.0.1])
	by hub.org (8.10.1/8.10.1) with SMTP id e6OMUmh59689;
	Mon, 24 Jul 2000 18:30:48 -0400 (EDT)
Received: from anubis (anubis.ip23.net [212.83.32.60])
	by hub.org (8.10.1/8.10.1) with ESMTP id e6OMTxh58656
	for <pgsql-hackers@hub.org>; Mon, 24 Jul 2000 18:29:59 -0400 (EDT)
Received: from ip23.net (umbriel [212.83.32.61]) by anubis (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id AAA96097; Tue, 25 Jul 2000 00:29:42 +0200 (CEST)
Message-ID: <397CC356.7C78A018@ip23.net>
Date: Tue, 25 Jul 2000 00:29:42 +0200
From: Sevo Stille <sevo@ip23.net>
Reply-To: sevo@ip23.net
Organization: IP23
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en-GB,en,de,en-US
MIME-Version: 1.0
To: Larry Rosenman <ler@lerctr.org>
CC: pgsql-hackers@hub.org
Subject: Re: [HACKERS] INET/CIDR types
References: <NCBBKBDOOHHEJCJHLLPAMELAHIAA.ler@lerctr.org>
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

Larry Rosenman wrote:
> 
> The problem is NON-TECHNICAL people will be getting the output,
> and they expect 4 octet output.

Well, but what are they going to do if they see, say, that 196.100.0.0
is already allocated? Any CIDR net starting off on the .0 will have
exactly the same 4 octet notation. That is, the above entry would only
tell that there is some indeterminable number of addresses starting off
196.100.0.0 allocated, which could be anything between a measly /31 and
a whopping big /16. To repeat: CIDR having no implicit netmask encoded
in the class, there is no way of figuring out your allocation if you
lose the explicit mask. Which presumably will cause considerable
problems in a network allocation and tracking application!
 
> I really think that we should have a way to coerce a CIDR to
> an INET, and then allow host().

There is no unique mapping of a CIDR network to a INET host address,
except for the special case of /32. 
 
> Remember that I am dealing with $10/hour clerks.

Then given them a interface which makes the concept of CIDR obvious to
them. Faking a classed notation is no way to go! IP v.4 being what it
is, and registries being on the move to enforce CIDR more and more, they
will inevitably encounter CIDR sooner or later, probably in a business
critical way.  
 
> I really don't get the hostility to changing the OUTPUT format...

Anything broken that is added will sooner or later be used by somebody.
Which means that it can't be fixed without breaking some applications.
That alone should be a good enough reason not to introduce any broken
notions intentionally.

Sevo

-- 
Sevo Stille
sevo@ip23.net

From pgsql-hackers-owner+M5279@hub.org Mon Jul 24 18:31:24 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 SAA12809
	for <pgman@candle.pha.pa.us>; Mon, 24 Jul 2000 18:31:23 -0400 (EDT)
Received: from hub.org (majordom@localhost [127.0.0.1])
	by hub.org (8.10.1/8.10.1) with SMTP id e6OMVBh60018;
	Mon, 24 Jul 2000 18:31:11 -0400 (EDT)
Received: from paprika.michvhf.com (paprika.michvhf.com [209.103.136.12])
	by hub.org (8.10.1/8.10.1) with SMTP id e6OMUrh59759
	for <pgsql-hackers@hub.org>; Mon, 24 Jul 2000 18:30:53 -0400 (EDT)
Received: (qmail 39846 invoked by uid 1001); 24 Jul 2000 22:30:59 -0000
Date: Mon, 24 Jul 2000 18:30:59 -0400 (EDT)
From: Vince Vielhaber <vev@michvhf.com>
To: Larry Rosenman <ler@lerctr.org>
cc: pgsql-hackers@hub.org
Subject: RE: [HACKERS] INET/CIDR types
In-Reply-To: <NCBBKBDOOHHEJCJHLLPAIELMHIAA.ler@lerctr.org>
Message-ID: <Pine.BSF.4.21.0007241828230.36999-100000@paprika.michvhf.com>
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, 24 Jul 2000, Larry Rosenman wrote:

> Can we dig up the RFC?

Feel free.  You can start your research with RFC1467 and look back at
what it touches on, then on to 1517, 1518 and 1519 then to 1817 and 
then to 2317.  If, after reading these, you don't understand why and/or
why not you can check with Paul himself at www.vix.com, 'cuze if you
don't understand then he's your only hope.

Vince.
-- 
==========================================================================
Vince Vielhaber -- KA8CSH    email: vev@michvhf.com    http://www.pop4.net
 128K ISDN from $22.00/mo - 56K Dialup from $16.00/mo at Pop4 Networking
        Online Campground Directory    http://www.camping-usa.com
       Online Giftshop Superstore    http://www.cloudninegifts.com
==========================================================================




From pgsql-hackers-owner+M5280@hub.org Mon Jul 24 18:53:56 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 SAA12905
	for <pgman@candle.pha.pa.us>; Mon, 24 Jul 2000 18:53:55 -0400 (EDT)
Received: from hub.org (majordom@localhost [127.0.0.1])
	by hub.org (8.10.1/8.10.1) with SMTP id e6OMrjh74011;
	Mon, 24 Jul 2000 18:53:45 -0400 (EDT)
Received: from anubis (anubis.ip23.net [212.83.32.60])
	by hub.org (8.10.1/8.10.1) with ESMTP id e6OMrNh73763
	for <pgsql-hackers@hub.org>; Mon, 24 Jul 2000 18:53:24 -0400 (EDT)
Received: from ip23.net (umbriel [212.83.32.61]) by anubis (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id AAA95973; Tue, 25 Jul 2000 00:52:30 +0200 (CEST)
Message-ID: <397CC8AE.FC342360@ip23.net>
Date: Tue, 25 Jul 2000 00:52:30 +0200
From: Sevo Stille <sevo@ip23.net>
Reply-To: sevo@ip23.net
Organization: IP23
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en-GB,en,de,en-US
MIME-Version: 1.0
To: Larry Rosenman <ler@lerctr.org>
CC: pgsql-hackers@hub.org, Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] INET/CIDR types
References: <NCBBKBDOOHHEJCJHLLPAAELHHIAA.ler@lerctr.org>
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

Larry Rosenman wrote:
> 
> What RFC says you can't print all 4 octets of a CIDR Netnumber?

Implicitly in 1518, for example:
---------8<----------------------8<----------------------8<------------
For the purposes of this paper, an IP prefix is an IP address and
   some indication of the leftmost contiguous significant bits within
   this address. 
---------8<----------------------8<----------------------8<------------

As I already explained, the use of variable-length masks implies that
they have to be explicitly stated. This was not neccessary in classed
networks, as the MSB's encoded the class (mask).

> Why does network(cidr) return the whole cidr output just like
> select cidr?

Because a cast to network is a cast to CIDR - casting to the same type
obviously won't change a thing. 
 
> I'm just trying to figure out the logic here.

As a matter of fact, it is the side effect of the current
implementations shortcomings - we have common code for INET and CIDR,
otherwise, network would not have to be a valid operator for CIDR.
 
> Here is what my Cisco Router that speaks BGP says:
> big-bro#term ip netmask-format bit-count
> big-bro#sh ip bg 206.66.0.0/20
> BGP routing table entry for 206.66.0.0/20, version 150832
> Paths: (5 available, best #4)
>   Advertised to non peer-group peers:
>     157.130.140.109 166.63.135.33 206.66.12.3 206.66.12.4 206.66.12.7
> 206.66.12.
> ...
> I am just asking for the same type output.

Huh? The only *network* I see in there IS in /bits notation.
 
Sevo

-- 
Sevo Stille
sevo@ip23.net

From pgsql-hackers-owner+M5282@hub.org Mon Jul 24 19:05:38 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 TAA13152
	for <pgman@candle.pha.pa.us>; Mon, 24 Jul 2000 19:05: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 e6ON5Mh82281;
	Mon, 24 Jul 2000 19:05:22 -0400 (EDT)
Received: from smtp.pacifier.com (comet.pacifier.com [199.2.117.155])
	by hub.org (8.10.1/8.10.1) with ESMTP id e6ON4qh81966
	for <pgsql-hackers@hub.org>; Mon, 24 Jul 2000 19:04:52 -0400 (EDT)
Received: from desktop (dsl-dhogaza.pacifier.net [207.202.226.68])
	by smtp.pacifier.com (8.9.3/8.9.3pop) with SMTP id QAA16750;
	Mon, 24 Jul 2000 16:04:27 -0700 (PDT)
Message-Id: <3.0.1.32.20000724160016.01192100@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Mon, 24 Jul 2000 16:00:16 -0700
To: Vince Vielhaber <vev@michvhf.com>, Larry Rosenman <ler@lerctr.org>
From: Don Baccus <dhogaza@pacifier.com>
Subject: RE: [HACKERS] INET/CIDR types
Cc: pgsql-hackers@hub.org
In-Reply-To: <Pine.BSF.4.21.0007241828230.36999-100000@paprika.michvhf.c
	om>
References: <NCBBKBDOOHHEJCJHLLPAIELMHIAA.ler@lerctr.org>
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

At 06:30 PM 7/24/00 -0400, Vince Vielhaber wrote:
>On Mon, 24 Jul 2000, Larry Rosenman wrote:
>
>> Can we dig up the RFC?
>
>Feel free.  You can start your research with RFC1467 and look back at
>what it touches on, then on to 1517, 1518 and 1519 then to 1817 and 
>then to 2317.  If, after reading these, you don't understand why and/or
>why not you can check with Paul himself at www.vix.com, 'cuze if you
>don't understand then he's your only hope.

I bet just hacking your PHP script to format it in the way you want
would involve a heck of a lot less effort ...



- Don Baccus, Portland OR <dhogaza@pacifier.com>
  Nature photos, on-line guides, Pacific Northwest
  Rare Bird Alert Service and other goodies at
  http://donb.photo.net.

From pgsql-hackers-owner+M5281@hub.org Mon Jul 24 19:01:25 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 TAA12969
	for <pgman@candle.pha.pa.us>; Mon, 24 Jul 2000 19:01:25 -0400 (EDT)
Received: from hub.org (majordom@localhost [127.0.0.1])
	by hub.org (8.10.1/8.10.1) with SMTP id e6ON1Dh79863;
	Mon, 24 Jul 2000 19:01:13 -0400 (EDT)
Received: from lerami.lerctr.org (lerami.lerctr.org [207.158.72.11])
	by hub.org (8.10.1/8.10.1) with ESMTP id e6ON0rh79630
	for <pgsql-hackers@hub.org>; Mon, 24 Jul 2000 19:00:53 -0400 (EDT)
Received: (from ler@localhost)
	by lerami.lerctr.org (8.10.1/8.10.1/20000715) id e6ON0lO03554;
	Mon, 24 Jul 2000 18:00:47 -0500 (CDT)
From: Larry Rosenman <ler@lerctr.org>
Message-Id: <200007242300.e6ON0lO03554@lerami.lerctr.org>
Subject: Re: [HACKERS] INET/CIDR types
In-Reply-To: <397CC8AE.FC342360@ip23.net> "from Sevo Stille at Jul 25, 2000 00:52:30
	am"
To: sevo@ip23.net
Date: Mon, 24 Jul 2000 18:00:46 -0500 (CDT)
CC: Larry Rosenman <ler@lerctr.org>, pgsql-hackers@hub.org,
        Don Baccus <dhogaza@pacifier.com>
X-Mailer: ELM [version 2.4ME+ PL79 (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

> Larry Rosenman wrote:
> > 
> > What RFC says you can't print all 4 octets of a CIDR Netnumber?
> 
> Implicitly in 1518, for example:
> ---------8<----------------------8<----------------------8<------------
> For the purposes of this paper, an IP prefix is an IP address and
>    some indication of the leftmost contiguous significant bits within
>    this address. 
> ---------8<----------------------8<----------------------8<------------
This doesn't prohibit listing all 4 octets, which is my argument...
> 
> As I already explained, the use of variable-length masks implies that
> they have to be explicitly stated. This was not neccessary in classed
> networks, as the MSB's encoded the class (mask).
I know this...
> 
> > Why does network(cidr) return the whole cidr output just like
> > select cidr?
> 
> Because a cast to network is a cast to CIDR - casting to the same type
> obviously won't change a thing. 
>  
> > I'm just trying to figure out the logic here.
> 
> As a matter of fact, it is the side effect of the current
> implementations shortcomings - we have common code for INET and CIDR,
> otherwise, network would not have to be a valid operator for CIDR.

I just want something equivalent to host(inet) that
prints all 4 octets of a CIDR type with no mask. 

Is that hard?
>  
> > Here is what my Cisco Router that speaks BGP says:
> > big-bro#term ip netmask-format bit-count
> > big-bro#sh ip bg 206.66.0.0/20
> > BGP routing table entry for 206.66.0.0/20, version 150832
> > Paths: (5 available, best #4)
> >   Advertised to non peer-group peers:
> >     157.130.140.109 166.63.135.33 206.66.12.3 206.66.12.4 206.66.12.7
> > 206.66.12.
> > ...
> > I am just asking for the same type output.
> 
> Huh? The only *network* I see in there IS in /bits notation.
Yes, but with all 4 octets, which is all I'm looking for....


>  
> Sevo
> 
> -- 
> Sevo Stille
> sevo@ip23.net


-- 
Larry Rosenman                      http://www.lerctr.org/~ler
Phone: +1 972-414-9812 (voice) Internet: ler@lerctr.org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749

From pgsql-hackers-owner+M5285@hub.org Mon Jul 24 22:17: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 WAA22852
	for <pgman@candle.pha.pa.us>; Mon, 24 Jul 2000 22:17: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 e6P2CVh51074;
	Mon, 24 Jul 2000 22:12:31 -0400 (EDT)
Received: from spider.pilosoft.com (p55-222.acedsl.com [160.79.55.222])
	by hub.org (8.10.1/8.10.1) with ESMTP id e6P2Boh50884
	for <pgsql-hackers@hub.org>; Mon, 24 Jul 2000 22:11:50 -0400 (EDT)
Received: from localhost (alexmail@localhost)
	by spider.pilosoft.com (8.9.3/8.9.3) with ESMTP id WAA03783;
	Mon, 24 Jul 2000 22:13:58 -0400 (EDT)
Date: Mon, 24 Jul 2000 22:13:57 -0400 (EDT)
From: Alex Pilosov <alex@pilosoft.com>
To: Sevo Stille <sevo@ip23.net>
cc: Larry Rosenman <ler@lerctr.org>, pgsql-hackers@hub.org
Subject: Re: [HACKERS] INET/CIDR types
In-Reply-To: <397CC356.7C78A018@ip23.net>
Message-ID: <Pine.BSO.4.10.10007242208480.4362-100000@spider.pilosoft.com>
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

This whole discussion is quite silly guys.

It is quite reasonable to have ability to split CIDR net into two pieces:
the network and the bitshift. Second one is already possible, the first
one can be accomplished by having functions to convert a cidr/inet to int8
(not int4 because of sign thing), and back.

Its also very easy to implement ;)

This will actually come very useful for many applications. Something I'm
working on now (allocation of 'most appropriate' block) requires ability
to split a netblock into two, which could be most easily accomplished
using int8 math. (net::int8+2^(netmask(net)-1)).

Now, patch anyone? :)
-alex
On Tue, 25 Jul 2000, Sevo Stille wrote:

> Larry Rosenman wrote:
> > 
> > The problem is NON-TECHNICAL people will be getting the output,
> > and they expect 4 octet output.
> 
> Well, but what are they going to do if they see, say, that 196.100.0.0
> is already allocated? Any CIDR net starting off on the .0 will have
> exactly the same 4 octet notation. That is, the above entry would only
> tell that there is some indeterminable number of addresses starting off
> 196.100.0.0 allocated, which could be anything between a measly /31 and
> a whopping big /16. To repeat: CIDR having no implicit netmask encoded
> in the class, there is no way of figuring out your allocation if you
> lose the explicit mask. Which presumably will cause considerable
> problems in a network allocation and tracking application!
>  
> > I really think that we should have a way to coerce a CIDR to
> > an INET, and then allow host().
> 
> There is no unique mapping of a CIDR network to a INET host address,
> except for the special case of /32. 
>  
> > Remember that I am dealing with $10/hour clerks.
> 
> Then given them a interface which makes the concept of CIDR obvious to
> them. Faking a classed notation is no way to go! IP v.4 being what it
> is, and registries being on the move to enforce CIDR more and more, they
> will inevitably encounter CIDR sooner or later, probably in a business
> critical way.  
>  
> > I really don't get the hostility to changing the OUTPUT format...
> 
> Anything broken that is added will sooner or later be used by somebody.
> Which means that it can't be fixed without breaking some applications.
> That alone should be a good enough reason not to introduce any broken
> notions intentionally.
> 
> Sevo
> 
> 


From pgsql-hackers-owner+M5287@hub.org Mon Jul 24 22:48:05 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 WAA23082
	for <pgman@candle.pha.pa.us>; Mon, 24 Jul 2000 22:48:04 -0400 (EDT)
Received: from hub.org (majordom@localhost [127.0.0.1])
	by hub.org (8.10.1/8.10.1) with SMTP id e6P2hrh58014;
	Mon, 24 Jul 2000 22:43:53 -0400 (EDT)
Received: from lerami.lerctr.org (lerami.lerctr.org [207.158.72.11])
	by hub.org (8.10.1/8.10.1) with ESMTP id e6P2hbh57922
	for <pgsql-hackers@hub.org>; Mon, 24 Jul 2000 22:43:37 -0400 (EDT)
Received: (from ler@localhost)
	by lerami.lerctr.org (8.10.1/8.10.1/20000715) id e6P2eVl12604;
	Mon, 24 Jul 2000 21:40:31 -0500 (CDT)
From: Larry Rosenman <ler@lerctr.org>
Message-Id: <200007250240.e6P2eVl12604@lerami.lerctr.org>
Subject: Re: [HACKERS] INET/CIDR types
In-Reply-To: <Pine.BSO.4.10.10007242208480.4362-100000@spider.pilosoft.com>
	"from Alex Pilosov at Jul 24, 2000 10:13:57 pm"
To: Alex Pilosov <alex@pilosoft.com>
Date: Mon, 24 Jul 2000 21:40:31 -0500 (CDT)
CC: Sevo Stille <sevo@ip23.net>, Larry Rosenman <ler@lerctr.org>,
        pgsql-hackers@hub.org
X-Mailer: ELM [version 2.4ME+ PL79 (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

> This whole discussion is quite silly guys.
> 
> It is quite reasonable to have ability to split CIDR net into two pieces:
> the network and the bitshift. Second one is already possible, the first
> one can be accomplished by having functions to convert a cidr/inet to int8
> (not int4 because of sign thing), and back.
> 
> Its also very easy to implement ;)
> 
> This will actually come very useful for many applications. Something I'm
> working on now (allocation of 'most appropriate' block) requires ability
> to split a netblock into two, which could be most easily accomplished
> using int8 math. (net::int8+2^(netmask(net)-1)).
All I'm looking for is to be able to print all 4 octets of an IP address
out so that joe user can take the 4 numbers and type it into the 
4 boxes on a Windows 98 box, and use them. 

Is that really that abhorrent?

They also need the 4 octet netmask which I can get now. 

All we are missing is a way to print ALL 4 NUMBERS ALL THE TIME
for the output.  It's not asking for classful, and for sure
we use CIDR all over the place, but for the final output that my
users see, why can't I have the database just print all 4 octets?

Why is this discussion so hard?

Larry
> 
> Now, patch anyone? :)
> -alex
> On Tue, 25 Jul 2000, Sevo Stille wrote:
> 
> > Larry Rosenman wrote:
> > > 
> > > The problem is NON-TECHNICAL people will be getting the output,
> > > and they expect 4 octet output.
> > 
> > Well, but what are they going to do if they see, say, that 196.100.0.0
> > is already allocated? Any CIDR net starting off on the .0 will have
> > exactly the same 4 octet notation. That is, the above entry would only
> > tell that there is some indeterminable number of addresses starting off
> > 196.100.0.0 allocated, which could be anything between a measly /31 and
> > a whopping big /16. To repeat: CIDR having no implicit netmask encoded
> > in the class, there is no way of figuring out your allocation if you
> > lose the explicit mask. Which presumably will cause considerable
> > problems in a network allocation and tracking application!
> >  
> > > I really think that we should have a way to coerce a CIDR to
> > > an INET, and then allow host().
> > 
> > There is no unique mapping of a CIDR network to a INET host address,
> > except for the special case of /32. 
> >  
> > > Remember that I am dealing with $10/hour clerks.
> > 
> > Then given them a interface which makes the concept of CIDR obvious to
> > them. Faking a classed notation is no way to go! IP v.4 being what it
> > is, and registries being on the move to enforce CIDR more and more, they
> > will inevitably encounter CIDR sooner or later, probably in a business
> > critical way.  
> >  
> > > I really don't get the hostility to changing the OUTPUT format...
> > 
> > Anything broken that is added will sooner or later be used by somebody.
> > Which means that it can't be fixed without breaking some applications.
> > That alone should be a good enough reason not to introduce any broken
> > notions intentionally.
> > 
> > Sevo
> > 
> > 
> 


-- 
Larry Rosenman                      http://www.lerctr.org/~ler
Phone: +1 972-414-9812 (voice) Internet: ler@lerctr.org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749

From pgsql-hackers-owner+M5288@hub.org Mon Jul 24 22:51:31 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 WAA23098
	for <pgman@candle.pha.pa.us>; Mon, 24 Jul 2000 22:51:30 -0400 (EDT)
Received: from hub.org (majordom@localhost [127.0.0.1])
	by hub.org (8.10.1/8.10.1) with SMTP id e6P2omh59374;
	Mon, 24 Jul 2000 22:50:48 -0400 (EDT)
Received: from spider.pilosoft.com (p55-222.acedsl.com [160.79.55.222])
	by hub.org (8.10.1/8.10.1) with ESMTP id e6P2oah59301
	for <pgsql-hackers@hub.org>; Mon, 24 Jul 2000 22:50:36 -0400 (EDT)
Received: from localhost (alexmail@localhost)
	by spider.pilosoft.com (8.9.3/8.9.3) with ESMTP id WAA03944;
	Mon, 24 Jul 2000 22:53:20 -0400 (EDT)
Date: Mon, 24 Jul 2000 22:53:20 -0400 (EDT)
From: Alex Pilosov <alex@pilosoft.com>
To: Larry Rosenman <ler@lerctr.org>
cc: Sevo Stille <sevo@ip23.net>, pgsql-hackers@hub.org
Subject: Re: [HACKERS] INET/CIDR types
In-Reply-To: <200007250240.e6P2eVl12604@lerami.lerctr.org>
Message-ID: <Pine.BSO.4.10.10007242252290.4362-100000@spider.pilosoft.com>
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, 24 Jul 2000, Larry Rosenman wrote:

> > This whole discussion is quite silly guys.
> > 
> > It is quite reasonable to have ability to split CIDR net into two pieces:
> > the network and the bitshift. Second one is already possible, the first
> > one can be accomplished by having functions to convert a cidr/inet to int8
> > (not int4 because of sign thing), and back.
> > 
> > Its also very easy to implement ;)
> > 
> > This will actually come very useful for many applications. Something I'm
> > working on now (allocation of 'most appropriate' block) requires ability
> > to split a netblock into two, which could be most easily accomplished
> > using int8 math. (net::int8+2^(netmask(net)-1)).
> All I'm looking for is to be able to print all 4 octets of an IP address
> out so that joe user can take the 4 numbers and type it into the 
> 4 boxes on a Windows 98 box, and use them. 
> 
> Is that really that abhorrent?
> 
> They also need the 4 octet netmask which I can get now. 
> 
> All we are missing is a way to print ALL 4 NUMBERS ALL THE TIME
> for the output.  It's not asking for classful, and for sure
> we use CIDR all over the place, but for the final output that my
> users see, why can't I have the database just print all 4 octets?

Larry, 
With my suggestion, you can do it as follows:

net::int8::inet

(net being of cidr type)
-alex


From pgsql-hackers-owner+M5290@hub.org Mon Jul 24 23:10:44 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 XAA23371
	for <pgman@candle.pha.pa.us>; Mon, 24 Jul 2000 23:10:44 -0400 (EDT)
Received: from hub.org (majordom@localhost [127.0.0.1])
	by hub.org (8.10.1/8.10.1) with SMTP id e6P3ATh64149;
	Mon, 24 Jul 2000 23:10:29 -0400 (EDT)
Received: from lerami.lerctr.org (lerami.lerctr.org [207.158.72.11])
	by hub.org (8.10.1/8.10.1) with ESMTP id e6P3AAh64000
	for <pgsql-hackers@hub.org>; Mon, 24 Jul 2000 23:10:10 -0400 (EDT)
Received: (from ler@localhost)
	by lerami.lerctr.org (8.10.1/8.10.1/20000715) id e6P3A1v13825;
	Mon, 24 Jul 2000 22:10:01 -0500 (CDT)
From: Larry Rosenman <ler@lerctr.org>
Message-Id: <200007250310.e6P3A1v13825@lerami.lerctr.org>
Subject: Re: [HACKERS] INET/CIDR types
In-Reply-To: <Pine.BSO.4.10.10007242252290.4362-100000@spider.pilosoft.com>
	"from Alex Pilosov at Jul 24, 2000 10:53:20 pm"
To: Alex Pilosov <alex@pilosoft.com>
Date: Mon, 24 Jul 2000 22:10:01 -0500 (CDT)
CC: Larry Rosenman <ler@lerctr.org>, Sevo Stille <sevo@ip23.net>,
        pgsql-hackers@hub.org
X-Mailer: ELM [version 2.4ME+ PL79 (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

The bad news is it doesn't work now...


ler=# select host(netblock::int8::inet) from networks;
ERROR:  Cannot cast type 'cidr' to 'int8'
ler=# \d networks
            Table "networks"
	       Attribute   |     Type     | Modifier 
	       ---------------+--------------+----------
	        netblock      | cidr         | 
		 router        | integer      | 
		  interface     | varchar(64)  | 
		   dest_ip       | inet         | 
		    net_name      | varchar(64)  | 
		     owner         | integer      | 
		      origin        | varchar(256) | 
		       assigned_date | date         | 
		        assigned_by   | varchar(64)  | 
			 asn           | smallint     | 

			 ler=# 

> On Mon, 24 Jul 2000, Larry Rosenman wrote:
> 
> > > This whole discussion is quite silly guys.
> > > 
> > > It is quite reasonable to have ability to split CIDR net into two pieces:
> > > the network and the bitshift. Second one is already possible, the first
> > > one can be accomplished by having functions to convert a cidr/inet to int8
> > > (not int4 because of sign thing), and back.
> > > 
> > > Its also very easy to implement ;)
> > > 
> > > This will actually come very useful for many applications. Something I'm
> > > working on now (allocation of 'most appropriate' block) requires ability
> > > to split a netblock into two, which could be most easily accomplished
> > > using int8 math. (net::int8+2^(netmask(net)-1)).
> > All I'm looking for is to be able to print all 4 octets of an IP address
> > out so that joe user can take the 4 numbers and type it into the 
> > 4 boxes on a Windows 98 box, and use them. 
> > 
> > Is that really that abhorrent?
> > 
> > They also need the 4 octet netmask which I can get now. 
> > 
> > All we are missing is a way to print ALL 4 NUMBERS ALL THE TIME
> > for the output.  It's not asking for classful, and for sure
> > we use CIDR all over the place, but for the final output that my
> > users see, why can't I have the database just print all 4 octets?
> 
> Larry, 
> With my suggestion, you can do it as follows:
> 
> net::int8::inet
> 
> (net being of cidr type)
> -alex
> 


-- 
Larry Rosenman                      http://www.lerctr.org/~ler
Phone: +1 972-414-9812 (voice) Internet: ler@lerctr.org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749

From pgsql-hackers-owner+M5291@hub.org Mon Jul 24 23:24:11 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 XAA23433
	for <pgman@candle.pha.pa.us>; Mon, 24 Jul 2000 23:24:10 -0400 (EDT)
Received: from hub.org (majordom@localhost [127.0.0.1])
	by hub.org (8.10.1/8.10.1) with SMTP id e6P3Nfh69885;
	Mon, 24 Jul 2000 23:23:41 -0400 (EDT)
Received: from spider.pilosoft.com (p55-222.acedsl.com [160.79.55.222])
	by hub.org (8.10.1/8.10.1) with ESMTP id e6P3Mvh69635
	for <pgsql-hackers@hub.org>; Mon, 24 Jul 2000 23:22:57 -0400 (EDT)
Received: from localhost (alexmail@localhost)
	by spider.pilosoft.com (8.9.3/8.9.3) with ESMTP id XAA27580;
	Mon, 24 Jul 2000 23:25:41 -0400 (EDT)
Date: Mon, 24 Jul 2000 23:25:41 -0400 (EDT)
From: Alex Pilosov <alex@pilosoft.com>
To: Larry Rosenman <ler@lerctr.org>
cc: Sevo Stille <sevo@ip23.net>, pgsql-hackers@hub.org
Subject: Re: [HACKERS] INET/CIDR types
In-Reply-To: <200007250310.e6P3A1v13825@lerami.lerctr.org>
Message-ID: <Pine.BSO.4.10.10007242314200.4362-100000@spider.pilosoft.com>
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

Yes, I know. 
I didn't say it existed, I proposed to create a simple conversion function
that would do that, which is why I asked for a patch.

I'd do it myself but it'll take some time. Should be really simple,
something to the effect of return a.s_addr (where a is struct in_addr),
however, I'm not sure what's POSIXly correct way to do that.



On Mon, 24 Jul 2000, Larry Rosenman wrote:

> The bad news is it doesn't work now...
> 
> 
> ler=# select host(netblock::int8::inet) from networks;
> ERROR:  Cannot cast type 'cidr' to 'int8'
> ler=# \d networks
>             Table "networks"
> 	       Attribute   |     Type     | Modifier 
> 	       ---------------+--------------+----------
> 	        netblock      | cidr         | 
> 		 router        | integer      | 
> 		  interface     | varchar(64)  | 
> 		   dest_ip       | inet         | 
> 		    net_name      | varchar(64)  | 
> 		     owner         | integer      | 
> 		      origin        | varchar(256) | 
> 		       assigned_date | date         | 
> 		        assigned_by   | varchar(64)  | 
> 			 asn           | smallint     | 
> 
> 			 ler=# 
> 
> > On Mon, 24 Jul 2000, Larry Rosenman wrote:
> > 
> > > > This whole discussion is quite silly guys.
> > > > 
> > > > It is quite reasonable to have ability to split CIDR net into two pieces:
> > > > the network and the bitshift. Second one is already possible, the first
> > > > one can be accomplished by having functions to convert a cidr/inet to int8
> > > > (not int4 because of sign thing), and back.
> > > > 
> > > > Its also very easy to implement ;)
> > > > 
> > > > This will actually come very useful for many applications. Something I'm
> > > > working on now (allocation of 'most appropriate' block) requires ability
> > > > to split a netblock into two, which could be most easily accomplished
> > > > using int8 math. (net::int8+2^(netmask(net)-1)).
> > > All I'm looking for is to be able to print all 4 octets of an IP address
> > > out so that joe user can take the 4 numbers and type it into the 
> > > 4 boxes on a Windows 98 box, and use them. 
> > > 
> > > Is that really that abhorrent?
> > > 
> > > They also need the 4 octet netmask which I can get now. 
> > > 
> > > All we are missing is a way to print ALL 4 NUMBERS ALL THE TIME
> > > for the output.  It's not asking for classful, and for sure
> > > we use CIDR all over the place, but for the final output that my
> > > users see, why can't I have the database just print all 4 octets?
> > 
> > Larry, 
> > With my suggestion, you can do it as follows:
> > 
> > net::int8::inet
> > 
> > (net being of cidr type)
> > -alex
> > 
> 
> 
> 


From pgsql-hackers-owner+M5292@hub.org Tue Jul 25 01:27:56 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 BAA25020
	for <pgman@candle.pha.pa.us>; Tue, 25 Jul 2000 01:27:56 -0400 (EDT)
Received: from hub.org (majordom@localhost [127.0.0.1])
	by hub.org (8.10.1/8.10.1) with SMTP id e6P5RWh12976;
	Tue, 25 Jul 2000 01:27:32 -0400 (EDT)
Received: from smtp.pacifier.com (comet.pacifier.com [199.2.117.155])
	by hub.org (8.10.1/8.10.1) with ESMTP id e6P5PHh12429
	for <pgsql-hackers@hub.org>; Tue, 25 Jul 2000 01:25:17 -0400 (EDT)
Received: from desktop (dsl-dhogaza.pacifier.net [207.202.226.68])
	by smtp.pacifier.com (8.9.3/8.9.3pop) with SMTP id WAA04370;
	Mon, 24 Jul 2000 22:25:00 -0700 (PDT)
Message-Id: <3.0.1.32.20000724221204.01198400@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Mon, 24 Jul 2000 22:12:04 -0700
To: Larry Rosenman <ler@lerctr.org>, Alex Pilosov <alex@pilosoft.com>
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] INET/CIDR types
Cc: Sevo Stille <sevo@ip23.net>, Larry Rosenman <ler@lerctr.org>,
        pgsql-hackers@hub.org
In-Reply-To: <200007250240.e6P2eVl12604@lerami.lerctr.org>
References: <Pine.BSO.4.10.10007242208480.4362-100000@spider.pilosoft.com>
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

At 09:40 PM 7/24/00 -0500, Larry Rosenman wrote:

>Why is this discussion so hard?

Because it's an output format you could easily solve yourself.  Could've
solved yourself long ago.

If you care so much, change the sources and run your own custom version.
The beauty of open source, you get to break it in whatever manner you
choose.

Or hack your PHP script.

If you need help hacking your script you can probably get help, here.  I'm
sure people are tired enough of this thread to write it for you, if that's
necessary.

Next I suppose you'll ask that Unix "ls" output switch "/" to
"\" so your $10 clerks can understand the output?



- Don Baccus, Portland OR <dhogaza@pacifier.com>
  Nature photos, on-line guides, Pacific Northwest
  Rare Bird Alert Service and other goodies at
  http://donb.photo.net.

From pgsql-hackers-owner+M5321@hub.org Tue Jul 25 16:45:35 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 QAA19032
	for <pgman@candle.pha.pa.us>; Tue, 25 Jul 2000 16:45:34 -0400 (EDT)
Received: from hub.org (majordom@localhost [127.0.0.1])
	by hub.org (8.10.1/8.10.1) with SMTP id e6PKieh98955;
	Tue, 25 Jul 2000 16:44:40 -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 e6PKenh96652
	for <pgsql-hackers@hub.org>; Tue, 25 Jul 2000 16:40:49 -0400 (EDT)
Received: from regulus.student.UU.SE ([130.238.5.2]:40690 "EHLO
        regulus.its.uu.se") by merganser.its.uu.se with ESMTP
	id <S291004AbQGYUkH>; Tue, 25 Jul 2000 22:40:07 +0200
Received: from peter (helo=localhost)
	by regulus.its.uu.se with local-esmtp (Exim 3.02 #2)
	id 13HBVx-0001cn-00; Tue, 25 Jul 2000 22:41:21 +0200
Date:   Tue, 25 Jul 2000 22:41:21 +0200 (CEST)
From: Peter Eisentraut <peter_e@gmx.net>
To: pgsql-hackers@hub.org
cc: Larry Rosenman <ler@lerctr.org>
Subject: Re: [HACKERS] INET/CIDR types
In-Reply-To: <m13Gngs-000AXeC@druid.net>
Message-ID: <Pine.LNX.4.21.0007251905480.546-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:

> Hmmm.  I just noticed this.
> 
> darcy=> select '1.2.0.1/23'::cidr;
> ?column?
> --------
> 1.2.0/23
> (1 row)
> 
> Shouldn't that throw an error?

Isn't that what I've been saying all along?


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


From pgsql-hackers-owner+M5370@hub.org Thu Jul 27 06:17:36 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 GAA24699
	for <pgman@candle.pha.pa.us>; Thu, 27 Jul 2000 06:17:35 -0400 (EDT)
Received: from hub.org (majordom@localhost [127.0.0.1])
	by hub.org (8.10.1/8.10.1) with SMTP id e6RAHRA44622;
	Thu, 27 Jul 2000 06:17:27 -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 e6RAH2A44416
	for <pgsql-hackers@hub.org>; Thu, 27 Jul 2000 06:17:02 -0400 (EDT)
Received: from localhost (1387 bytes) by druid.net
	via sendmail with P:stdio/R:bind_hosts/T:inet_zone_bind_smtp
	(sender: <darcy>) (ident <darcy> using unix)
	id <m13Hkik-000AX9C@druid.net>
	for <pgsql-hackers@hub.org>; Thu, 27 Jul 2000 06:16:54 -0400 (EDT)
	(Smail-3.2.0.109 1999-Oct-27 #3 built 2000-Jun-28)
Message-Id: <m13Hkik-000AX9C@druid.net>
From: darcy@druid.net (D'Arcy J.M. Cain)
Subject: Re: [HACKERS] INET/CIDR types
In-Reply-To: <Pine.LNX.4.21.0007251905480.546-100000@localhost.localdomain>
	"from Peter Eisentraut at Jul 25, 2000 10:41:21 pm"
To: Peter Eisentraut <peter_e@gmx.net>
Date: Thu, 27 Jul 2000 06:16:54 -0400 (EDT)
CC: pgsql-hackers@hub.org, Larry Rosenman <ler@lerctr.org>
Reply-To: pgsql-hackers@hub.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
> > Hmmm.  I just noticed this.
> > 
> > darcy=> select '1.2.0.1/23'::cidr;
> > ?column?
> > --------
> > 1.2.0/23
> > (1 row)
> > 
> > Shouldn't that throw an error?
> 
> Isn't that what I've been saying all along?

Well, yes but I thought that it was now and that you were arguing to keep
that behaviour.  This seems to be the behaviour that I was suggesting
although you have half convinced me that this should throw an error.

So, it looks like the status quo is for inet::cidr to be a different
spelling for network(inet).  Is this the way we want to keep it?

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