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.