From 1c753e1ffb32d4168414bf9de7856a760bf0e120 Mon Sep 17 00:00:00 2001 From: Bruce Momjian Date: Thu, 27 Jul 2000 19:11:47 +0000 Subject: [PATCH] Add cidr TODO.detai file. --- doc/TODO | 1 + doc/TODO.detail/cidr | 2769 ++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 2770 insertions(+) create mode 100644 doc/TODO.detail/cidr diff --git a/doc/TODO b/doc/TODO index e3d9f8336b..45d1bae508 100644 --- a/doc/TODO +++ b/doc/TODO @@ -80,6 +80,7 @@ TYPES o Allow large object vacuuming o Tables that start with xinv confused to be large objects * Add IPv6 capability to INET/CIDR types +* Fix improper masking of some inet/cidr types [cidr] * Make a separate SERIAL type? * Store binary-compatible type information in the system * Add support for & operator diff --git a/doc/TODO.detail/cidr b/doc/TODO.detail/cidr new file mode 100644 index 0000000000..1a6479c062 --- /dev/null +++ b/doc/TODO.detail/cidr @@ -0,0 +1,2769 @@ +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 ; 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 ; 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 ; 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 +To: PostgreSQL Development +Subject: [HACKERS] Repair plan for inet and cidr types +Message-ID: +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 ; 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 ; 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: ) (ident using unix) + id + for ; Tue, 4 Jul 2000 22:13:06 -0400 (EDT) + (Smail-3.2.0.109 1999-Oct-27 #3 built 2000-Jun-28) +Message-Id: +From: darcy@druid.net (D'Arcy J.M. Cain) +Subject: Re: [HACKERS] Repair plan for inet and cidr types +In-Reply-To: + "from Peter Eisentraut at Jul 5, 2000 02:12:35 am" +To: Peter Eisentraut +Date: Tue, 4 Jul 2000 22:13:06 -0400 (EDT) +CC: PostgreSQL Development +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 | 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 ; 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 ; 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: ) (ident using unix) + id + for ; Tue, 4 Jul 2000 22:19:49 -0400 (EDT) + (Smail-3.2.0.109 1999-Oct-27 #3 built 2000-Jun-28) +Message-Id: +From: darcy@druid.net (D'Arcy J.M. Cain) +Subject: Re: [HACKERS] Repair plan for inet and cidr types +In-Reply-To: + "from Peter Eisentraut at Jul 5, 2000 02:12:35 am" +To: Peter Eisentraut +Date: Tue, 4 Jul 2000 22:19:49 -0400 (EDT) +CC: PostgreSQL Development +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 | 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 ; 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 ; 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 +cc: PostgreSQL Development +Subject: Re: [HACKERS] Repair plan for inet and cidr types +In-reply-to: +References: +Comments: In-reply-to Peter Eisentraut + 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 +X-Mailing-List: pgsql-hackers@postgresql.org +Precedence: bulk +Sender: pgsql-hackers-owner@hub.org +Status: OR + +Peter Eisentraut 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 ; 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 ; 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 ; Wed, 5 Jul 2000 14:44:01 +0200 +Date: Wed, 5 Jul 2000 14:43:49 +0200 (MET DST) +From: Jakub Bartosz Bielecki +To: Sevo Stille +cc: Jakub Bartosz Bielecki , + pgsql-hackers@PostgreSQL.org +Subject: Re: [HACKERS] Re: postgres - development of inet/cidr +In-Reply-To: <3960A5FE.E626BAE1@ip23.net> +Message-ID: +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 ; 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 ; 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 ; Wed, 5 Jul 2000 14:52:43 +0200 +Date: Wed, 5 Jul 2000 14:52:33 +0200 (MET DST) +From: Jakub Bartosz Bielecki +To: pgsql-patches@postgresql.org +Subject: [PATCHES] Re: [HACKERS] Re: postgres - development of inet/cidr +Message-ID: +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: +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 ; 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 ; 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 +To: "D'Arcy J.M. Cain" +cc: PostgreSQL Development +Subject: Re: [HACKERS] Repair plan for inet and cidr types +In-Reply-To: +Message-ID: +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 ; 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 ; 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 +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 +CC: pgsql-hackers@PostgreSQL.org +Subject: Re: [HACKERS] Re: postgres - development of inet/cidr +References: +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 ; 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 ; 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: ) (ident using unix) + id + for ; Wed, 5 Jul 2000 16:46:48 -0400 (EDT) + (Smail-3.2.0.109 1999-Oct-27 #3 built 2000-Jun-28) +Message-Id: +From: darcy@druid.net (D'Arcy J.M. Cain) +Subject: Re: [HACKERS] Repair plan for inet and cidr types +In-Reply-To: + "from eisentrp@csis.gvsu.edu at Jul 5, 2000 09:02:17 am" +To: Peter Eisentraut +Date: Wed, 5 Jul 2000 16:46:48 -0400 (EDT) +CC: PostgreSQL Development +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 | 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 ; 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 ; 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 ; Thu, 6 Jul 2000 14:52:28 +0200 +Date: Thu, 6 Jul 2000 14:52:17 +0200 (MET DST) +From: Jakub Bartosz Bielecki +To: Sevo Stille +cc: Jakub Bartosz Bielecki , + pgsql-hackers@PostgreSQL.org +Subject: Re: [HACKERS] Re: postgres - development of inet/cidr +In-Reply-To: <39633C99.DD58D11F@ip23.net> +Message-ID: +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 ; 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 ; 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 ; 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 +To: "D'Arcy J.M. Cain" +cc: PostgreSQL Development +Subject: Re: [HACKERS] Repair plan for inet and cidr types +In-Reply-To: +Message-ID: +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 ; 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 ; 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 +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 ; 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 ; 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: ) (ident using unix) + id + for ; Mon, 24 Jul 2000 10:33:15 -0400 (EDT) + (Smail-3.2.0.109 1999-Oct-27 #3 built 2000-Jun-28) +Message-Id: +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 +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 | 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 ; 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 ; 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 +Message-Id: <200007241441.e6OEf5D12433@lerami.lerctr.org> +Subject: Re: [HACKERS] INET/CIDR types +In-Reply-To: "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 +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 | 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 ; 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 ; 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: ) (ident using unix) + id + for ; Mon, 24 Jul 2000 15:15:02 -0400 (EDT) + (Smail-3.2.0.109 1999-Oct-27 #3 built 2000-Jun-28) +Message-Id: +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 +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 | 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 ; 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 ; 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" +To: , "Larry Rosenman" +Subject: RE: [HACKERS] INET/CIDR types +Date: Mon, 24 Jul 2000 14:26:37 -0500 +Message-ID: +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: +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 | 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 ; 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 ; 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" , , + "Larry Rosenman" +From: Don Baccus +Subject: RE: [HACKERS] INET/CIDR types +In-Reply-To: +References: +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 + 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 ; 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 ; 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" +To: "Don Baccus" , "Larry Rosenman" , + , "Larry Rosenman" +Subject: RE: [HACKERS] INET/CIDR types +Date: Mon, 24 Jul 2000 14:36:44 -0500 +Message-ID: +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 + 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 ; 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 ; 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: ) (ident using unix) + id + for ; Mon, 24 Jul 2000 16:17:36 -0400 (EDT) + (Smail-3.2.0.109 1999-Oct-27 #3 built 2000-Jun-28) +Message-Id: +From: darcy@druid.net (D'Arcy J.M. Cain) +Subject: Re: [HACKERS] INET/CIDR types +In-Reply-To: "from Larry Rosenman + at Jul 24, 2000 02:36:44 pm" +To: Larry Rosenman +Date: Mon, 24 Jul 2000 16:17:36 -0400 (EDT) +CC: Don Baccus , 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 | 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 ; 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 ; 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" +To: , "Larry Rosenman" +Cc: "Don Baccus" +Subject: RE: [HACKERS] INET/CIDR types +Date: Mon, 24 Jul 2000 15:27:24 -0500 +Message-ID: +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: +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 | 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 ; 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 ; 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: ) (ident using unix) + id + for ; Mon, 24 Jul 2000 16:53:24 -0400 (EDT) + (Smail-3.2.0.109 1999-Oct-27 #3 built 2000-Jun-28) +Message-Id: +From: darcy@druid.net (D'Arcy J.M. Cain) +Subject: Re: [HACKERS] INET/CIDR types +In-Reply-To: "from Larry Rosenman + at Jul 24, 2000 03:27:24 pm" +To: Larry Rosenman +Date: Mon, 24 Jul 2000 16:53:24 -0400 (EDT) +CC: pgsql-hackers@hub.org, Don Baccus +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 | 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 ; 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 ; 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" +To: , "Larry Rosenman" +Cc: "Don Baccus" +Subject: RE: [HACKERS] INET/CIDR types +Date: Mon, 24 Jul 2000 16:11:34 -0500 +Message-ID: +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: +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 | 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 ; 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 ; 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 +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 +CC: pgsql-hackers@hub.org +Subject: Re: [HACKERS] INET/CIDR types +References: +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 ; 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 ; 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 +To: Larry Rosenman +cc: pgsql-hackers@hub.org +Subject: RE: [HACKERS] INET/CIDR types +In-Reply-To: +Message-ID: +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 ; 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 ; 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 +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 +CC: pgsql-hackers@hub.org, Don Baccus +Subject: Re: [HACKERS] INET/CIDR types +References: +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 ; 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 ; 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 , Larry Rosenman +From: Don Baccus +Subject: RE: [HACKERS] INET/CIDR types +Cc: pgsql-hackers@hub.org +In-Reply-To: +References: +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 + 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 ; 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 ; 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 +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 , pgsql-hackers@hub.org, + Don Baccus +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 ; 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 ; 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 +To: Sevo Stille +cc: Larry Rosenman , pgsql-hackers@hub.org +Subject: Re: [HACKERS] INET/CIDR types +In-Reply-To: <397CC356.7C78A018@ip23.net> +Message-ID: +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 ; 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 ; 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 +Message-Id: <200007250240.e6P2eVl12604@lerami.lerctr.org> +Subject: Re: [HACKERS] INET/CIDR types +In-Reply-To: + "from Alex Pilosov at Jul 24, 2000 10:13:57 pm" +To: Alex Pilosov +Date: Mon, 24 Jul 2000 21:40:31 -0500 (CDT) +CC: Sevo Stille , Larry Rosenman , + 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 ; 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 ; 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 +To: Larry Rosenman +cc: Sevo Stille , pgsql-hackers@hub.org +Subject: Re: [HACKERS] INET/CIDR types +In-Reply-To: <200007250240.e6P2eVl12604@lerami.lerctr.org> +Message-ID: +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 ; 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 ; 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 +Message-Id: <200007250310.e6P3A1v13825@lerami.lerctr.org> +Subject: Re: [HACKERS] INET/CIDR types +In-Reply-To: + "from Alex Pilosov at Jul 24, 2000 10:53:20 pm" +To: Alex Pilosov +Date: Mon, 24 Jul 2000 22:10:01 -0500 (CDT) +CC: Larry Rosenman , Sevo Stille , + 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 ; 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 ; 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 +To: Larry Rosenman +cc: Sevo Stille , pgsql-hackers@hub.org +Subject: Re: [HACKERS] INET/CIDR types +In-Reply-To: <200007250310.e6P3A1v13825@lerami.lerctr.org> +Message-ID: +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 ; 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 ; 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 , Alex Pilosov +From: Don Baccus +Subject: Re: [HACKERS] INET/CIDR types +Cc: Sevo Stille , Larry Rosenman , + pgsql-hackers@hub.org +In-Reply-To: <200007250240.e6P2eVl12604@lerami.lerctr.org> +References: +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 + 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 ; 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 ; 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 ; 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 +To: pgsql-hackers@hub.org +cc: Larry Rosenman +Subject: Re: [HACKERS] INET/CIDR types +In-Reply-To: +Message-ID: +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 ; 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 ; 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: ) (ident using unix) + id + for ; Thu, 27 Jul 2000 06:16:54 -0400 (EDT) + (Smail-3.2.0.109 1999-Oct-27 #3 built 2000-Jun-28) +Message-Id: +From: darcy@druid.net (D'Arcy J.M. Cain) +Subject: Re: [HACKERS] INET/CIDR types +In-Reply-To: + "from Peter Eisentraut at Jul 25, 2000 10:41:21 pm" +To: Peter Eisentraut +Date: Thu, 27 Jul 2000 06:16:54 -0400 (EDT) +CC: pgsql-hackers@hub.org, Larry Rosenman +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 | 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. +