--- /dev/null
+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.
+
OSDN Git Service
