mirror of
https://git.postgresql.org/git/postgresql.git
synced 2024-08-22 05:03:23 +02:00
2770 lines
112 KiB
Plaintext
2770 lines
112 KiB
Plaintext
From pgsql-hackers-owner+M4219@hub.org Tue Jul 4 20:10:16 2000
|
||
Received: from hub.org (root@hub.org [216.126.84.1])
|
||
by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id UAA13204
|
||
for <pgman@candle.pha.pa.us>; Tue, 4 Jul 2000 20:10:15 -0400 (EDT)
|
||
Received: from hub.org (majordom@localhost [127.0.0.1])
|
||
by hub.org (8.10.1/8.10.1) with SMTP id e650A8S29252;
|
||
Tue, 4 Jul 2000 20:10:08 -0400 (EDT)
|
||
Received: from merganser.its.uu.se (merganser.its.uu.se [130.238.6.236])
|
||
by hub.org (8.10.1/8.10.1) with ESMTP id e6505pS14530
|
||
for <pgsql-hackers@postgresql.org>; Tue, 4 Jul 2000 20:05:52 -0400 (EDT)
|
||
Received: from regulus.student.UU.SE ([130.238.5.2]:37402 "EHLO
|
||
regulus.its.uu.se") by merganser.its.uu.se with ESMTP
|
||
id <S176281AbQGEAFU>; Wed, 5 Jul 2000 02:05:20 +0200
|
||
Received: from peter (helo=localhost)
|
||
by regulus.its.uu.se with local-esmtp (Exim 3.02 #2)
|
||
id 139cnr-0003QO-00
|
||
for pgsql-hackers@postgresql.org; Wed, 05 Jul 2000 02:12:35 +0200
|
||
Date: Wed, 5 Jul 2000 02:12:35 +0200 (CEST)
|
||
From: Peter Eisentraut <peter_e@gmx.net>
|
||
To: PostgreSQL Development <pgsql-hackers@postgresql.org>
|
||
Subject: [HACKERS] Repair plan for inet and cidr types
|
||
Message-ID: <Pine.LNX.4.21.0007050118110.3542-100000@localhost.localdomain>
|
||
MIME-Version: 1.0
|
||
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
|
||
Content-Transfer-Encoding: 8BIT
|
||
X-Mailing-List: pgsql-hackers@postgresql.org
|
||
Precedence: bulk
|
||
Sender: pgsql-hackers-owner@hub.org
|
||
Status: OR
|
||
|
||
As we know, the inet and cidr types are still broken in several ways,
|
||
amongst others input and output functions, operators, ordering. I've
|
||
collected the bug reports from the last year or so from the archives.
|
||
|
||
There's apparently a lack of understanding of what exactly are these types
|
||
are supposed to do. Therefore, instead of addressing each bug
|
||
individually, let me first state what I reconstructed as the specification
|
||
of these types, and then add what is currently wrong with it.
|
||
|
||
* CIDR
|
||
|
||
The cidr type stores the identity of an IP _network_. A network
|
||
specification is of the form 'x.x.x.x/y'. The documentation states that if
|
||
y is omitted then it is constructed from the old A, B, C class scheme. So
|
||
be it. In a real world network, the bits (y+1)...32 have to be zero, but
|
||
the cidr type does not currently enforce this. This has been the source of
|
||
bugs in the past, and no doubt the source of some confusion as well. I
|
||
propose that cidr _reject_ input of the form '127.0.0.5/16'. If you think
|
||
about it, this is the same as int4 rejecting 3.5 as input.
|
||
|
||
* INET
|
||
|
||
The inet type stores the identity of an IP _host_. A host specification is
|
||
of the form 'x.x.x.x'. Optionally, the inet type also stores the identity
|
||
of the network the host is in. E.g., '127.0.0.5/16' means the host
|
||
127.0.0.5 in the network 127.0/16.
|
||
|
||
* Type equivalency
|
||
|
||
This has also been a source of problems. I propose that cidr and inet are
|
||
not made equivalent types at any level. No automatic casting either. A
|
||
network and a host are not the same thing. To construct a cidr value from
|
||
an inet value, you'd have to use some sort of (to be created) network()
|
||
function, e.g., network('127.0.0.5/16') => '127.0/16'. IMO, there is no
|
||
reasonable way to construct an inet value from a cidr value.
|
||
|
||
* Operators
|
||
|
||
Because the types are equivalent, the operators have also been bunched
|
||
together in confusing ways. I propose that ordering operators (>, +, <)
|
||
between inet and cidr be eliminated, they do not make sense. The only
|
||
useful operation between cidr and inet is the << ("contains") operator.
|
||
Ordering withing cidr and inet be defined in terms of their bit
|
||
representation, as is the case now. The << family of operators should also
|
||
be removed for the inet type -- a host cannot "contain" another host. What
|
||
you probably wanted is `inet1 << network(inet2)'.
|
||
|
||
|
||
Does anyone see this differently? If not, can we agree on this
|
||
specification?
|
||
|
||
--
|
||
Peter Eisentraut Sernanders v<>g 10:115
|
||
peter_e@gmx.net 75262 Uppsala
|
||
http://yi.org/peter-e/ Sweden
|
||
|
||
|
||
From pgsql-hackers-owner+M4230@hub.org Tue Jul 4 22:13:37 2000
|
||
Received: from hub.org (root@hub.org [216.126.84.1])
|
||
by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id WAA13773
|
||
for <pgman@candle.pha.pa.us>; Tue, 4 Jul 2000 22:13:37 -0400 (EDT)
|
||
Received: from hub.org (majordom@localhost [127.0.0.1])
|
||
by hub.org (8.10.1/8.10.1) with SMTP id e652DSS19722;
|
||
Tue, 4 Jul 2000 22:13:28 -0400 (EDT)
|
||
Received: from druid.net (root@druid.net [216.126.72.98])
|
||
by hub.org (8.10.1/8.10.1) with ESMTP id e652D9S19504
|
||
for <pgsql-hackers@postgresql.org>; Tue, 4 Jul 2000 22:13:09 -0400 (EDT)
|
||
Received: from localhost (4223 bytes) by druid.net
|
||
via sendmail with P:stdio/R:bind_hosts/T:inet_zone_bind_smtp
|
||
(sender: <darcy>) (ident <darcy> using unix)
|
||
id <m139egU-000AXpC@druid.net>
|
||
for <pgsql-hackers@postgresql.org>; Tue, 4 Jul 2000 22:13:06 -0400 (EDT)
|
||
(Smail-3.2.0.109 1999-Oct-27 #3 built 2000-Jun-28)
|
||
Message-Id: <m139egU-000AXpC@druid.net>
|
||
From: darcy@druid.net (D'Arcy J.M. Cain)
|
||
Subject: Re: [HACKERS] Repair plan for inet and cidr types
|
||
In-Reply-To: <Pine.LNX.4.21.0007050118110.3542-100000@localhost.localdomain>
|
||
"from Peter Eisentraut at Jul 5, 2000 02:12:35 am"
|
||
To: Peter Eisentraut <peter_e@gmx.net>
|
||
Date: Tue, 4 Jul 2000 22:13:06 -0400 (EDT)
|
||
CC: PostgreSQL Development <pgsql-hackers@postgresql.org>
|
||
X-Mailer: ELM [version 2.4ME+ PL78 (25)]
|
||
MIME-Version: 1.0
|
||
Content-Transfer-Encoding: 7bit
|
||
Content-Type: text/plain; charset=US-ASCII
|
||
X-Mailing-List: pgsql-hackers@postgresql.org
|
||
Precedence: bulk
|
||
Sender: pgsql-hackers-owner@hub.org
|
||
Status: OR
|
||
|
||
Thus spake Peter Eisentraut
|
||
> There's apparently a lack of understanding of what exactly are these types
|
||
> are supposed to do. Therefore, instead of addressing each bug
|
||
> individually, let me first state what I reconstructed as the specification
|
||
> of these types, and then add what is currently wrong with it.
|
||
|
||
I have been browsing through the old messages on the topic. There was, in
|
||
fact some very good work defining the type before anyone actually started
|
||
to code. There was a surprising amount of controversy over the actual
|
||
definitions but I think in the end we hammered it out at least to the
|
||
point that everyone could work with it.
|
||
|
||
> * CIDR
|
||
>
|
||
> The cidr type stores the identity of an IP _network_. A network
|
||
> specification is of the form 'x.x.x.x/y'. The documentation states that if
|
||
> y is omitted then it is constructed from the old A, B, C class scheme. So
|
||
> be it. In a real world network, the bits (y+1)...32 have to be zero, but
|
||
> the cidr type does not currently enforce this. This has been the source of
|
||
> bugs in the past, and no doubt the source of some confusion as well. I
|
||
> propose that cidr _reject_ input of the form '127.0.0.5/16'. If you think
|
||
> about it, this is the same as int4 rejecting 3.5 as input.
|
||
|
||
There is also the option of accepting it but masking out the host bits
|
||
before storing it. That gives us automatic conversion if we store an
|
||
inet into a cidr if our intent is to store the network part.
|
||
|
||
What sort of bugs do you think it caused btw?
|
||
|
||
> * INET
|
||
>
|
||
> The inet type stores the identity of an IP _host_. A host specification is
|
||
> of the form 'x.x.x.x'. Optionally, the inet type also stores the identity
|
||
> of the network the host is in. E.g., '127.0.0.5/16' means the host
|
||
> 127.0.0.5 in the network 127.0/16.
|
||
|
||
That sounds right. We also allowed for hosts to be stored implicitely by
|
||
simply making the netmask /32.
|
||
|
||
> * Type equivalency
|
||
>
|
||
> This has also been a source of problems. I propose that cidr and inet are
|
||
> not made equivalent types at any level. No automatic casting either. A
|
||
> network and a host are not the same thing. To construct a cidr value from
|
||
> an inet value, you'd have to use some sort of (to be created) network()
|
||
> function, e.g., network('127.0.0.5/16') => '127.0/16'. IMO, there is no
|
||
> reasonable way to construct an inet value from a cidr value.
|
||
|
||
I'm not sure I understand why this is necessary. I can see not allowing
|
||
cidr ==> inet conversions but inet ==> cidr can be done as it is a matter
|
||
of dropping information - the host part.
|
||
|
||
|
||
> * Operators
|
||
>
|
||
> Because the types are equivalent, the operators have also been bunched
|
||
> together in confusing ways. I propose that ordering operators (>, +, <)
|
||
> between inet and cidr be eliminated, they do not make sense. The only
|
||
> useful operation between cidr and inet is the << ("contains") operator.
|
||
> Ordering withing cidr and inet be defined in terms of their bit
|
||
> representation, as is the case now. The << family of operators should also
|
||
> be removed for the inet type -- a host cannot "contain" another host. What
|
||
> you probably wanted is `inet1 << network(inet2)'.
|
||
|
||
Then let's define that as the meaning of "inet1 << inet2" i.e. define
|
||
the << operator between inet types as meaning "tell me if inet1 is in
|
||
the same network as inet2." In fact, if we define << as only allowed
|
||
between inet and cidr (or cidr and cidr?) then the implied cast will
|
||
deal with it if that cast causes the host bits to drop as suggested
|
||
above.
|
||
|
||
--
|
||
D'Arcy J.M. Cain <darcy@{druid|vex}.net> | Democracy is three wolves
|
||
http://www.druid.net/darcy/ | and a sheep voting on
|
||
+1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner.
|
||
|
||
From pgsql-hackers-owner+M4232@hub.org Tue Jul 4 22:20:30 2000
|
||
Received: from hub.org (root@hub.org [216.126.84.1])
|
||
by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id WAA13808
|
||
for <pgman@candle.pha.pa.us>; Tue, 4 Jul 2000 22:20:29 -0400 (EDT)
|
||
Received: from hub.org (majordom@localhost [127.0.0.1])
|
||
by hub.org (8.10.1/8.10.1) with SMTP id e652KDS33988;
|
||
Tue, 4 Jul 2000 22:20:13 -0400 (EDT)
|
||
Received: from druid.net (root@druid.net [216.126.72.98])
|
||
by hub.org (8.10.1/8.10.1) with ESMTP id e652JuS33839
|
||
for <pgsql-hackers@postgresql.org>; Tue, 4 Jul 2000 22:19:57 -0400 (EDT)
|
||
Received: from localhost (1460 bytes) by druid.net
|
||
via sendmail with P:stdio/R:bind_hosts/T:inet_zone_bind_smtp
|
||
(sender: <darcy>) (ident <darcy> using unix)
|
||
id <m139emz-000AXrC@druid.net>
|
||
for <pgsql-hackers@postgresql.org>; Tue, 4 Jul 2000 22:19:49 -0400 (EDT)
|
||
(Smail-3.2.0.109 1999-Oct-27 #3 built 2000-Jun-28)
|
||
Message-Id: <m139emz-000AXrC@druid.net>
|
||
From: darcy@druid.net (D'Arcy J.M. Cain)
|
||
Subject: Re: [HACKERS] Repair plan for inet and cidr types
|
||
In-Reply-To: <Pine.LNX.4.21.0007050118110.3542-100000@localhost.localdomain>
|
||
"from Peter Eisentraut at Jul 5, 2000 02:12:35 am"
|
||
To: Peter Eisentraut <peter_e@gmx.net>
|
||
Date: Tue, 4 Jul 2000 22:19:49 -0400 (EDT)
|
||
CC: PostgreSQL Development <pgsql-hackers@postgresql.org>
|
||
X-Mailer: ELM [version 2.4ME+ PL78 (25)]
|
||
MIME-Version: 1.0
|
||
Content-Transfer-Encoding: 7bit
|
||
Content-Type: text/plain; charset=US-ASCII
|
||
X-Mailing-List: pgsql-hackers@postgresql.org
|
||
Precedence: bulk
|
||
Sender: pgsql-hackers-owner@hub.org
|
||
Status: OR
|
||
|
||
Thus spake Peter Eisentraut
|
||
> network and a host are not the same thing. To construct a cidr value from
|
||
> an inet value, you'd have to use some sort of (to be created) network()
|
||
> function, e.g., network('127.0.0.5/16') => '127.0/16'. IMO, there is no
|
||
|
||
Oh, I forgot to mention:
|
||
|
||
darcy=> select network('127.1.2.3/24'::inet);
|
||
network
|
||
----------
|
||
127.1.2/24
|
||
(1 row)
|
||
|
||
There is also a host and netmask function and note:
|
||
|
||
darcy=> select host('127.1.2.3/24'::cidr);
|
||
ERROR: CIDR type has no host part
|
||
|
||
But I still see no reason why that can't be implicit if we assign the
|
||
"'127.1.2.3/24'::inet" value to a cidr. In other words let "select
|
||
('127.1.2.3/24'::inet)::cidr" give the same output.
|
||
|
||
--
|
||
D'Arcy J.M. Cain <darcy@{druid|vex}.net> | Democracy is three wolves
|
||
http://www.druid.net/darcy/ | and a sheep voting on
|
||
+1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner.
|
||
|
||
From pgsql-hackers-owner+M4234@hub.org Tue Jul 4 22:31:46 2000
|
||
Received: from hub.org (root@hub.org [216.126.84.1])
|
||
by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id WAA13855
|
||
for <pgman@candle.pha.pa.us>; Tue, 4 Jul 2000 22:31:46 -0400 (EDT)
|
||
Received: from hub.org (majordom@localhost [127.0.0.1])
|
||
by hub.org (8.10.1/8.10.1) with SMTP id e652VdS74063;
|
||
Tue, 4 Jul 2000 22:31:39 -0400 (EDT)
|
||
Received: from sss2.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
|
||
by hub.org (8.10.1/8.10.1) with ESMTP id e652VSS73985
|
||
for <pgsql-hackers@postgresql.org>; Tue, 4 Jul 2000 22:31:28 -0400 (EDT)
|
||
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
|
||
by sss2.sss.pgh.pa.us (8.9.3/8.9.3) with ESMTP id WAA29694;
|
||
Tue, 4 Jul 2000 22:31:26 -0400 (EDT)
|
||
To: Peter Eisentraut <peter_e@gmx.net>
|
||
cc: PostgreSQL Development <pgsql-hackers@postgresql.org>
|
||
Subject: Re: [HACKERS] Repair plan for inet and cidr types
|
||
In-reply-to: <Pine.LNX.4.21.0007050118110.3542-100000@localhost.localdomain>
|
||
References: <Pine.LNX.4.21.0007050118110.3542-100000@localhost.localdomain>
|
||
Comments: In-reply-to Peter Eisentraut <peter_e@gmx.net>
|
||
message dated "Wed, 05 Jul 2000 02:12:35 +0200"
|
||
Date: Tue, 04 Jul 2000 22:31:25 -0400
|
||
Message-ID: <29691.962764285@sss.pgh.pa.us>
|
||
From: Tom Lane <tgl@sss.pgh.pa.us>
|
||
X-Mailing-List: pgsql-hackers@postgresql.org
|
||
Precedence: bulk
|
||
Sender: pgsql-hackers-owner@hub.org
|
||
Status: OR
|
||
|
||
Peter Eisentraut <peter_e@gmx.net> writes:
|
||
> There's apparently a lack of understanding of what exactly are these types
|
||
> are supposed to do. Therefore, instead of addressing each bug
|
||
> individually, let me first state what I reconstructed as the specification
|
||
> of these types, and then add what is currently wrong with it.
|
||
|
||
This sounds good offhand, but then I never paid a whole lot of attention
|
||
to the details originally. Did you go through the original inet/cidr
|
||
design discussions (the threads where Paul Vixie was participating)?
|
||
|
||
I don't believe Paul is subscribed here anymore, but I'd feel a lot
|
||
happier if you can contact him and get him to sign off on the clarified
|
||
design. Maybe this is what he had in mind all along, or maybe not.
|
||
|
||
regards, tom lane
|
||
|
||
PS: You do know who Paul Vixie is, I assume ;-). I can think of few
|
||
better-qualified experts in this domain...
|
||
|
||
From pgsql-hackers-owner+M4312@hub.org Wed Jul 5 10:48:17 2000
|
||
Received: from hub.org (root@hub.org [216.126.84.1])
|
||
by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id KAA02483
|
||
for <pgman@candle.pha.pa.us>; Wed, 5 Jul 2000 10:48:16 -0400 (EDT)
|
||
Received: from hub.org (majordom@localhost [127.0.0.1])
|
||
by hub.org (8.10.1/8.10.1) with SMTP id e65EllS08607;
|
||
Wed, 5 Jul 2000 10:47:47 -0400 (EDT)
|
||
Received: from elektron.elka.pw.edu.pl (root@elektron.elka.pw.edu.pl [148.81.63.249])
|
||
by hub.org (8.10.1/8.10.1) with ESMTP id e65CiPS89307
|
||
for <pgsql-hackers@PostgreSQL.org>; Wed, 5 Jul 2000 08:44:55 -0400 (EDT)
|
||
Received: from elektron.elka.pw.edu.pl ([148.81.63.249]:41059 "EHLO
|
||
elektron.elka.pw.edu.pl") by elektron.elka.pw.edu.pl with ESMTP
|
||
id <S225388AbQGEMoB>; Wed, 5 Jul 2000 14:44:01 +0200
|
||
Date: Wed, 5 Jul 2000 14:43:49 +0200 (MET DST)
|
||
From: Jakub Bartosz Bielecki <J.B.Bielecki@elka.pw.edu.pl>
|
||
To: Sevo Stille <sevo@ip23.net>
|
||
cc: Jakub Bartosz Bielecki <J.B.Bielecki@elka.pw.edu.pl>,
|
||
pgsql-hackers@PostgreSQL.org
|
||
Subject: Re: [HACKERS] Re: postgres - development of inet/cidr
|
||
In-Reply-To: <3960A5FE.E626BAE1@ip23.net>
|
||
Message-ID: <Pine.SOL.4.21.0007051410330.1267-100000@elektron.elka.pw.edu.pl>
|
||
MIME-Version: 1.0
|
||
Content-Type: TEXT/PLAIN; charset=US-ASCII
|
||
X-Mailing-List: pgsql-hackers@postgresql.org
|
||
Precedence: bulk
|
||
Sender: pgsql-hackers-owner@hub.org
|
||
Status: OR
|
||
|
||
|
||
|
||
On Mon, 3 Jul 2000, Sevo Stille wrote:
|
||
>
|
||
> This would be proper behaviour for the cidr datatype, which describes a
|
||
> network. "select '10.0.0.1/27'::cidr='10.0.0.2/27'::cidr;" has to return
|
||
> true, as both define the same network, the mask putting the 1 vs. 2
|
||
> outside the comparison scope.
|
||
>
|
||
> On inet, I consider the above broken - going by the documentation,
|
||
> having a netmask on a inet datatype does not define a network address
|
||
> but rather supplies additional information on the cidr network the host
|
||
> as specified by the address is in. Accordingly, it should only truncate
|
||
> if the comparison casts to cidr.
|
||
|
||
OK. After some inspection in list's archives I found the following
|
||
statement (http://www.postgresql.org/mhonarc/pgsql-hackers/1998-07):
|
||
> It does not work that way. /24 is
|
||
> not a shorthand for specifying a netmask -- in CIDR, it's a "prefix
|
||
> length".
|
||
> That means "192.7.34.21/24" is either (a) a syntax error or
|
||
> (b) equivilent to "192.7.34/24".
|
||
|
||
Everybody seemed to agree with the above opinion at that time.
|
||
|
||
This is obviously _not_ the way that CIDR is handled at this moment.
|
||
"select '1.2.3.4/24'" returns "1.2.3/24" only because the _output_ routine
|
||
silently cuts host bits. Input routine stores it exactly as '1.2.3.4/24'.
|
||
|
||
Since IMHO it's wrong I prepared a patch (I'm sending it to pgsql-patch).
|
||
It fixes the CIDR input routine to zero host bits (ie beyond-prefix bits).
|
||
Please note that I didn't change the INET input routine.
|
||
|
||
Eventually I had to change a bit comparison functions.
|
||
To this moment they worked in a CIDR way (didn't compare host bits at all)
|
||
although they were used by both INET and CIDR.
|
||
Since CIDR is zero-padded now, whole 32 bits are compared by > = <
|
||
operators.
|
||
Subnet operators <<, >> are still the same, don't compare host bits.
|
||
|
||
> The big question is whether comparisons that only work on a cidr data
|
||
> type (contains/contained) or have a cidr type on one side can safely
|
||
> cast the inet type to cidr implicitly. For:
|
||
> "select '10.0.0.1/27'::inet = '10.0.0.2/27'::inet;" FALSE
|
||
> "select '10.0.0.1/27'::cidr = '10.0.0.2/27'::cidr;" TRUE
|
||
> "select '10.0.0.1/27'::cidr = '10.0.0.2/27'::inet;" FALSE
|
||
> "select '10.0.0.1/27'::cidr >> '10.0.0.2/27'::inet;" TRUE
|
||
OK.
|
||
> "select '10.0.0.1/27'::cidr << '10.0.0.2/27'::inet;" ERROR
|
||
|
||
Currently it's not an error... There is no way (and no reason) to
|
||
distinguish between INET and CIDR. Above example is exactly
|
||
equivalent to:
|
||
select '10.0.0.0/27'::inet << '10.0.0.2/27'::inet; -- FALSE
|
||
but:
|
||
select '10.0.0.0/27'::inet <<= '10.0.0.2/27'::inet; -- TRUE
|
||
|
||
> But we need to reach an agreement on the proper
|
||
> behaviour on greater/smaller comparisons. Should:
|
||
>
|
||
> "select '10.0.0.1/27'::inet > '10.0.0.2/27'::cidr;"
|
||
>
|
||
> be true or false? Casting to cidr prior to comparison would make it
|
||
> equivalent to "select '10.0.0.0/27'::cidr > '10.0.0.0/27'::cidr;", which
|
||
> is false, both networks being equal.
|
||
|
||
It should be (and is!) true... Since second argument is
|
||
really '10.0.0.0/27'.
|
||
|
||
|
||
From pgsql-patches-owner+M284@hub.org Wed Jul 5 09:03:39 2000
|
||
Received: from hub.org (root@hub.org [216.126.84.1])
|
||
by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id JAA27744
|
||
for <pgman@candle.pha.pa.us>; Wed, 5 Jul 2000 09:03:38 -0400 (EDT)
|
||
Received: from hub.org (majordom@localhost [127.0.0.1])
|
||
by hub.org (8.10.1/8.10.1) with SMTP id e65D3OS38516;
|
||
Wed, 5 Jul 2000 09:03:24 -0400 (EDT)
|
||
Received: from elektron.elka.pw.edu.pl (root@elektron.elka.pw.edu.pl [148.81.63.249])
|
||
by hub.org (8.10.1/8.10.1) with ESMTP id e65Cr5S11483
|
||
for <pgsql-patches@postgresql.org>; Wed, 5 Jul 2000 08:53:06 -0400 (EDT)
|
||
Received: from elektron.elka.pw.edu.pl ([148.81.63.249]:42221 "EHLO
|
||
elektron.elka.pw.edu.pl") by elektron.elka.pw.edu.pl with ESMTP
|
||
id <S225089AbQGEMwn>; Wed, 5 Jul 2000 14:52:43 +0200
|
||
Date: Wed, 5 Jul 2000 14:52:33 +0200 (MET DST)
|
||
From: Jakub Bartosz Bielecki <J.B.Bielecki@elka.pw.edu.pl>
|
||
To: pgsql-patches@postgresql.org
|
||
Subject: [PATCHES] Re: [HACKERS] Re: postgres - development of inet/cidr
|
||
Message-ID: <Pine.SOL.4.21.0007051446090.1267-200000@elektron.elka.pw.edu.pl>
|
||
MIME-Version: 1.0
|
||
Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-959030623-962801553=:1267"
|
||
X-Mailing-List: pgsql-patches@postgresql.org
|
||
Precedence: bulk
|
||
Sender: pgsql-patches-owner@hub.org
|
||
Status: OR
|
||
|
||
This message is in MIME format. The first part should be readable text,
|
||
while the remaining parts are likely unreadable without MIME-aware tools.
|
||
Send mail to mime@docserver.cac.washington.edu for more info.
|
||
|
||
---559023410-959030623-962801553=:1267
|
||
Content-Type: TEXT/PLAIN; charset=US-ASCII
|
||
|
||
|
||
1. Fixed obvious bug with strcpy() called on text type in network.c
|
||
2. Fixed CIDR input routine to cut 'host' bits in inet_net_pton.c
|
||
3. Changed network_{lt,gt,eq} to compare all bits of INET/CIDR in network.c
|
||
|
||
Jakub
|
||
|
||
---559023410-959030623-962801553=:1267
|
||
Content-Type: TEXT/PLAIN; charset=US-ASCII; name=inet-patch
|
||
Content-Transfer-Encoding: BASE64
|
||
Content-ID: <Pine.SOL.4.21.0007051452330.1267@elektron.elka.pw.edu.pl>
|
||
Content-Description: inet-patch
|
||
Content-Disposition: attachment; filename=inet-patch
|
||
|
||
KioqIC4vYmFja2VuZC91dGlscy9hZHQvaW5ldF9uZXRfcHRvbi5jLm9yaWcJ
|
||
VHVlIEp1bCAgNCAyMzowMDowNiAyMDAwDQotLS0gLi9iYWNrZW5kL3V0aWxz
|
||
L2FkdC9pbmV0X25ldF9wdG9uLmMJV2VkIEp1bCAgNSAxMToxMTozMiAyMDAw
|
||
DQoqKioqKioqKioqKioqKioNCioqKiAxMDEsMTA3ICoqKioNCiAgCQkJCXRt
|
||
cCwNCiAgCQkJCWRpcnR5LA0KICAJCQkJYml0czsNCiEgCWNvbnN0IHVfY2hh
|
||
ciAqb2RzdCA9IGRzdDsNCiAgDQogIAljaCA9ICpzcmMrKzsNCiAgCWlmIChj
|
||
aCA9PSAnMCcgJiYgKHNyY1swXSA9PSAneCcgfHwgc3JjWzBdID09ICdYJykN
|
||
Ci0tLSAxMDEsMTA3IC0tLS0NCiAgCQkJCXRtcCwNCiAgCQkJCWRpcnR5LA0K
|
||
ICAJCQkJYml0czsNCiEgCXVfY2hhciAqb2RzdCA9IGRzdDsNCiAgDQogIAlj
|
||
aCA9ICpzcmMrKzsNCiAgCWlmIChjaCA9PSAnMCcgJiYgKHNyY1swXSA9PSAn
|
||
eCcgfHwgc3JjWzBdID09ICdYJykNCioqKioqKioqKioqKioqKg0KKioqIDIx
|
||
MywyMTggKioqKg0KLS0tIDIxMywyMjYgLS0tLQ0KICAJCS8qIElmIGltcHV0
|
||
ZWQgbWFzayBpcyBuYXJyb3dlciB0aGFuIHNwZWNpZmllZCBvY3RldHMsIHdp
|
||
ZGVuLiAqLw0KICAJCWlmIChiaXRzID49IDggJiYgYml0cyA8ICgoZHN0IC0g
|
||
b2RzdCkgKiA4KSkNCiAgCQkJYml0cyA9IChkc3QgLSBvZHN0KSAqIDg7DQor
|
||
IAl9DQorIAkvKiBaZXJvIGhvc3QgYml0cyBpZiBhbnkgKi8NCisgCW4gPSBi
|
||
aXRzLzg7DQorIAlpZiggbiA8IChkc3QgLSBvZHN0KSApDQorIAl7DQorIAkJ
|
||
b2RzdFtuKytdICY9IFVDSEFSX01BWDw8KDggLSAoYml0cyAlIDgpKTsNCisg
|
||
CQlmb3IgKDtuIDwgKGRzdCAtIG9kc3QpOyBuKyspDQorIAkJCW9kc3Rbbl09
|
||
J1wwJzsNCiAgCX0NCiAgCS8qIEV4dGVuZCBuZXR3b3JrIHRvIGNvdmVyIHRo
|
||
ZSBhY3R1YWwgbWFzay4gKi8NCiAgCXdoaWxlIChiaXRzID4gKChkc3QgLSBv
|
||
ZHN0KSAqIDgpKQ0KKioqIC4vYmFja2VuZC91dGlscy9hZHQvbmV0d29yay5j
|
||
Lm9yaWcJVHVlIEp1bCAgNCAyMzowMjowMSAyMDAwDQotLS0gLi9iYWNrZW5k
|
||
L3V0aWxzL2FkdC9uZXR3b3JrLmMJVHVlIEp1bCAgNCAyMzozNToyMSAyMDAw
|
||
DQoqKioqKioqKioqKioqKioNCioqKiAxOCwyMyAqKioqDQotLS0gMTgsMjQg
|
||
LS0tLQ0KICAjaW5jbHVkZSAicG9zdGdyZXMuaCINCiAgI2luY2x1ZGUgInV0
|
||
aWxzL2J1aWx0aW5zLmgiDQogIA0KKyBzdGF0aWMgaW50CXY0Yml0Y21wKHVu
|
||
c2lnbmVkIGludCBhMSwgdW5zaWduZWQgaW50IGEyKTsNCiAgc3RhdGljIGlu
|
||
dAl2NGJpdG5jbXAodW5zaWduZWQgaW50IGExLCB1bnNpZ25lZCBpbnQgYTIs
|
||
IGludCBiaXRzKTsNCiAgDQogIC8qDQoqKioqKioqKioqKioqKioNCioqKiAx
|
||
MzcsMTQzICoqKioNCiAgCQlyZXR1cm4gRkFMU0U7DQogIAlpZiAoKGlwX2Zh
|
||
bWlseShhMSkgPT0gQUZfSU5FVCkgJiYgKGlwX2ZhbWlseShhMikgPT0gQUZf
|
||
SU5FVCkpDQogIAl7DQohIAkJaW50CQkJb3JkZXIgPSB2NGJpdG5jbXAoaXBf
|
||
djRhZGRyKGExKSwgaXBfdjRhZGRyKGEyKSwgaXBfYml0cyhhMikpOw0KICAN
|
||
CiAgCQlyZXR1cm4gKChvcmRlciA8IDApIHx8ICgob3JkZXIgPT0gMCkgJiYg
|
||
KGlwX2JpdHMoYTEpIDwgaXBfYml0cyhhMikpKSk7DQogIAl9DQotLS0gMTM4
|
||
LDE0NCAtLS0tDQogIAkJcmV0dXJuIEZBTFNFOw0KICAJaWYgKChpcF9mYW1p
|
||
bHkoYTEpID09IEFGX0lORVQpICYmIChpcF9mYW1pbHkoYTIpID09IEFGX0lO
|
||
RVQpKQ0KICAJew0KISAJCWludAkJCW9yZGVyID0gdjRiaXRjbXAoaXBfdjRh
|
||
ZGRyKGExKSwgaXBfdjRhZGRyKGEyKSk7DQogIA0KICAJCXJldHVybiAoKG9y
|
||
ZGVyIDwgMCkgfHwgKChvcmRlciA9PSAwKSAmJiAoaXBfYml0cyhhMSkgPCBp
|
||
cF9iaXRzKGEyKSkpKTsNCiAgCX0NCioqKioqKioqKioqKioqKg0KKioqIDE2
|
||
NiwxNzIgKioqKg0KICAJaWYgKChpcF9mYW1pbHkoYTEpID09IEFGX0lORVQp
|
||
ICYmIChpcF9mYW1pbHkoYTIpID09IEFGX0lORVQpKQ0KICAJew0KICAJCXJl
|
||
dHVybiAoKGlwX2JpdHMoYTEpID09IGlwX2JpdHMoYTIpKQ0KISAJCSAmJiAo
|
||
djRiaXRuY21wKGlwX3Y0YWRkcihhMSksIGlwX3Y0YWRkcihhMiksIGlwX2Jp
|
||
dHMoYTEpKSA9PSAwKSk7DQogIAl9DQogIAllbHNlDQogIAl7DQotLS0gMTY3
|
||
LDE3MyAtLS0tDQogIAlpZiAoKGlwX2ZhbWlseShhMSkgPT0gQUZfSU5FVCkg
|
||
JiYgKGlwX2ZhbWlseShhMikgPT0gQUZfSU5FVCkpDQogIAl7DQogIAkJcmV0
|
||
dXJuICgoaXBfYml0cyhhMSkgPT0gaXBfYml0cyhhMikpDQohIAkJICYmICh2
|
||
NGJpdGNtcChpcF92NGFkZHIoYTEpLCBpcF92NGFkZHIoYTIpKSA9PSAwKSk7
|
||
DQogIAl9DQogIAllbHNlDQogIAl7DQoqKioqKioqKioqKioqKioNCioqKiAx
|
||
OTIsMTk4ICoqKioNCiAgCQlyZXR1cm4gRkFMU0U7DQogIAlpZiAoKGlwX2Zh
|
||
bWlseShhMSkgPT0gQUZfSU5FVCkgJiYgKGlwX2ZhbWlseShhMikgPT0gQUZf
|
||
SU5FVCkpDQogIAl7DQohIAkJaW50CQkJb3JkZXIgPSB2NGJpdG5jbXAoaXBf
|
||
djRhZGRyKGExKSwgaXBfdjRhZGRyKGEyKSwgaXBfYml0cyhhMikpOw0KICAN
|
||
CiAgCQlyZXR1cm4gKChvcmRlciA+IDApIHx8ICgob3JkZXIgPT0gMCkgJiYg
|
||
KGlwX2JpdHMoYTEpID4gaXBfYml0cyhhMikpKSk7DQogIAl9DQotLS0gMTkz
|
||
LDE5OSAtLS0tDQogIAkJcmV0dXJuIEZBTFNFOw0KICAJaWYgKChpcF9mYW1p
|
||
bHkoYTEpID09IEFGX0lORVQpICYmIChpcF9mYW1pbHkoYTIpID09IEFGX0lO
|
||
RVQpKQ0KICAJew0KISAJCWludAkJCW9yZGVyID0gdjRiaXRjbXAoaXBfdjRh
|
||
ZGRyKGExKSwgaXBfdjRhZGRyKGEyKSk7DQogIA0KICAJCXJldHVybiAoKG9y
|
||
ZGVyID4gMCkgfHwgKChvcmRlciA9PSAwKSAmJiAoaXBfYml0cyhhMSkgPiBp
|
||
cF9iaXRzKGEyKSkpKTsNCiAgCX0NCioqKioqKioqKioqKioqKg0KKioqIDM0
|
||
MSwzNTMgKioqKg0KICANCiAgCWlmICgocHRyID0gc3RyY2hyKHRtcCwgJy8n
|
||
KSkgIT0gTlVMTCkNCiAgCQkqcHRyID0gMDsNCiEgCWxlbiA9IFZBUkhEUlNa
|
||
ICsgc3RybGVuKHRtcCkgKyAxOw0KICAJcmV0ID0gcGFsbG9jKGxlbik7DQog
|
||
IAlpZiAocmV0ID09IE5VTEwpDQogIAkJZWxvZyhFUlJPUiwgInVuYWJsZSB0
|
||
byBhbGxvY2F0ZSBtZW1vcnkgaW4gbmV0d29ya19ob3N0KCkiKTsNCiAgDQog
|
||
IAlWQVJTSVpFKHJldCkgPSBsZW47DQohIAlzdHJjcHkoVkFSREFUQShyZXQp
|
||
LCB0bXApOw0KICAJcmV0dXJuIChyZXQpOw0KICB9DQogIA0KLS0tIDM0Miwz
|
||
NTQgLS0tLQ0KICANCiAgCWlmICgocHRyID0gc3RyY2hyKHRtcCwgJy8nKSkg
|
||
IT0gTlVMTCkNCiAgCQkqcHRyID0gMDsNCiEgCWxlbiA9IFZBUkhEUlNaICsg
|
||
c3RybGVuKHRtcCk7DQogIAlyZXQgPSBwYWxsb2MobGVuKTsNCiAgCWlmIChy
|
||
ZXQgPT0gTlVMTCkNCiAgCQllbG9nKEVSUk9SLCAidW5hYmxlIHRvIGFsbG9j
|
||
YXRlIG1lbW9yeSBpbiBuZXR3b3JrX2hvc3QoKSIpOw0KICANCiAgCVZBUlNJ
|
||
WkUocmV0KSA9IGxlbjsNCiEgCW1lbWNweShWQVJEQVRBKHJldCksIHRtcCwg
|
||
bGVuLVZBUkhEUlNaKTsNCiAgCXJldHVybiAocmV0KTsNCiAgfQ0KICANCioq
|
||
KioqKioqKioqKioqKg0KKioqIDM5MSw0MDMgKioqKg0KICANCiAgCWlmICgo
|
||
cHRyID0gc3RyY2hyKHRtcCwgJy8nKSkgIT0gTlVMTCkNCiAgCQkqcHRyID0g
|
||
MDsNCiEgCWxlbiA9IFZBUkhEUlNaICsgc3RybGVuKHRtcCkgKyAxOw0KICAJ
|
||
cmV0ID0gcGFsbG9jKGxlbik7DQogIAlpZiAocmV0ID09IE5VTEwpDQogIAkJ
|
||
ZWxvZyhFUlJPUiwgInVuYWJsZSB0byBhbGxvY2F0ZSBtZW1vcnkgaW4gbmV0
|
||
d29ya19icm9hZGNhc3QoKSIpOw0KICANCiAgCVZBUlNJWkUocmV0KSA9IGxl
|
||
bjsNCiEgCXN0cmNweShWQVJEQVRBKHJldCksIHRtcCk7DQogIAlyZXR1cm4g
|
||
KHJldCk7DQogIH0NCiAgDQotLS0gMzkyLDQwNCAtLS0tDQogIA0KICAJaWYg
|
||
KChwdHIgPSBzdHJjaHIodG1wLCAnLycpKSAhPSBOVUxMKQ0KICAJCSpwdHIg
|
||
PSAwOw0KISAJbGVuID0gVkFSSERSU1ogKyBzdHJsZW4odG1wKTsNCiAgCXJl
|
||
dCA9IHBhbGxvYyhsZW4pOw0KICAJaWYgKHJldCA9PSBOVUxMKQ0KICAJCWVs
|
||
b2coRVJST1IsICJ1bmFibGUgdG8gYWxsb2NhdGUgbWVtb3J5IGluIG5ldHdv
|
||
cmtfYnJvYWRjYXN0KCkiKTsNCiAgDQogIAlWQVJTSVpFKHJldCkgPSBsZW47
|
||
DQohIAltZW1jcHkoVkFSREFUQShyZXQpLCB0bXAsIGxlbi1WQVJIRFJTWik7
|
||
DQogIAlyZXR1cm4gKHJldCk7DQogIH0NCiAgDQoqKioqKioqKioqKioqKioN
|
||
CioqKiA0MjQsNDM2ICoqKioNCiAgCQkvKiBHbyBmb3IgYW4gSVBWNiBhZGRy
|
||
ZXNzIGhlcmUsIGJlZm9yZSBmYXVsdGluZyBvdXQ6ICovDQogIAkJZWxvZyhF
|
||
UlJPUiwgInVua25vd24gYWRkcmVzcyBmYW1pbHkgKCVkKSIsIGlwX2ZhbWls
|
||
eShpcCkpOw0KICANCiEgCWxlbiA9IFZBUkhEUlNaICsgc3RybGVuKHRtcCkg
|
||
KyAxOw0KICAJcmV0ID0gcGFsbG9jKGxlbik7DQogIAlpZiAocmV0ID09IE5V
|
||
TEwpDQogIAkJZWxvZyhFUlJPUiwgInVuYWJsZSB0byBhbGxvY2F0ZSBtZW1v
|
||
cnkgaW4gbmV0d29ya19uZXR3b3JrKCkiKTsNCiAgDQogIAlWQVJTSVpFKHJl
|
||
dCkgPSBsZW47DQohIAlzdHJjcHkoVkFSREFUQShyZXQpLCB0bXApOw0KICAJ
|
||
cmV0dXJuIChyZXQpOw0KICB9DQogIA0KLS0tIDQyNSw0MzcgLS0tLQ0KICAJ
|
||
CS8qIEdvIGZvciBhbiBJUFY2IGFkZHJlc3MgaGVyZSwgYmVmb3JlIGZhdWx0
|
||
aW5nIG91dDogKi8NCiAgCQllbG9nKEVSUk9SLCAidW5rbm93biBhZGRyZXNz
|
||
IGZhbWlseSAoJWQpIiwgaXBfZmFtaWx5KGlwKSk7DQogIA0KISAJbGVuID0g
|
||
VkFSSERSU1ogKyBzdHJsZW4odG1wKTsNCiAgCXJldCA9IHBhbGxvYyhsZW4p
|
||
Ow0KICAJaWYgKHJldCA9PSBOVUxMKQ0KICAJCWVsb2coRVJST1IsICJ1bmFi
|
||
bGUgdG8gYWxsb2NhdGUgbWVtb3J5IGluIG5ldHdvcmtfbmV0d29yaygpIik7
|
||
DQogIA0KICAJVkFSU0laRShyZXQpID0gbGVuOw0KISAJbWVtY3B5KFZBUkRB
|
||
VEEocmV0KSwgdG1wLCBsZW4tVkFSSERSU1opOw0KICAJcmV0dXJuIChyZXQp
|
||
Ow0KICB9DQogIA0KKioqKioqKioqKioqKioqDQoqKiogNDYxLDQ3OSAqKioq
|
||
DQogIA0KICAJaWYgKChwdHIgPSBzdHJjaHIodG1wLCAnLycpKSAhPSBOVUxM
|
||
KQ0KICAJCSpwdHIgPSAwOw0KISAJbGVuID0gVkFSSERSU1ogKyBzdHJsZW4o
|
||
dG1wKSArIDE7DQogIAlyZXQgPSBwYWxsb2MobGVuKTsNCiAgCWlmIChyZXQg
|
||
PT0gTlVMTCkNCiAgCQllbG9nKEVSUk9SLCAidW5hYmxlIHRvIGFsbG9jYXRl
|
||
IG1lbW9yeSBpbiBuZXR3b3JrX25ldG1hc2soKSIpOw0KICANCiAgCVZBUlNJ
|
||
WkUocmV0KSA9IGxlbjsNCiEgCXN0cmNweShWQVJEQVRBKHJldCksIHRtcCk7
|
||
DQogIAlyZXR1cm4gKHJldCk7DQogIH0NCiAgDQogIC8qDQogICAqCUJpdHdp
|
||
c2UgY29tcGFyaXNvbiBmb3IgVjQgYWRkcmVzc2VzLiAgQWRkIFY2IGltcGxl
|
||
bWVudGF0aW9uIQ0KICAgKi8NCiAgDQogIHN0YXRpYyBpbnQNCiAgdjRiaXRu
|
||
Y21wKHVuc2lnbmVkIGludCBhMSwgdW5zaWduZWQgaW50IGEyLCBpbnQgYml0
|
||
cykNCi0tLSA0NjIsNDkxIC0tLS0NCiAgDQogIAlpZiAoKHB0ciA9IHN0cmNo
|
||
cih0bXAsICcvJykpICE9IE5VTEwpDQogIAkJKnB0ciA9IDA7DQohIAlsZW4g
|
||
PSBWQVJIRFJTWiArIHN0cmxlbih0bXApOw0KICAJcmV0ID0gcGFsbG9jKGxl
|
||
bik7DQogIAlpZiAocmV0ID09IE5VTEwpDQogIAkJZWxvZyhFUlJPUiwgInVu
|
||
YWJsZSB0byBhbGxvY2F0ZSBtZW1vcnkgaW4gbmV0d29ya19uZXRtYXNrKCki
|
||
KTsNCiAgDQogIAlWQVJTSVpFKHJldCkgPSBsZW47DQohIAltZW1jcHkoVkFS
|
||
REFUQShyZXQpLCB0bXAsIGxlbi1WQVJIRFJTWik7DQogIAlyZXR1cm4gKHJl
|
||
dCk7DQogIH0NCiAgDQogIC8qDQogICAqCUJpdHdpc2UgY29tcGFyaXNvbiBm
|
||
b3IgVjQgYWRkcmVzc2VzLiAgQWRkIFY2IGltcGxlbWVudGF0aW9uIQ0KICAg
|
||
Ki8NCisgDQorIHN0YXRpYyBpbnQNCisgdjRiaXRjbXAodW5zaWduZWQgaW50
|
||
IGExLCB1bnNpZ25lZCBpbnQgYTIpDQorIHsNCisgCWExID0gbnRvaGwoYTEp
|
||
Ow0KKyAJYTIgPSBudG9obChhMik7DQorIAlpZiAoYTEgPCBhMikNCisgCQly
|
||
ZXR1cm4gKC0xKTsNCisgCWVsc2UgDQorIAkJcmV0dXJuIChhMSA+IGEyKTsN
|
||
CisgfQ0KICANCiAgc3RhdGljIGludA0KICB2NGJpdG5jbXAodW5zaWduZWQg
|
||
aW50IGExLCB1bnNpZ25lZCBpbnQgYTIsIGludCBiaXRzKQ0K
|
||
|
||
---559023410-959030623-962801553=:1267--
|
||
|
||
From pgsql-hackers-owner+M4284@hub.org Wed Jul 5 09:04:09 2000
|
||
Received: from hub.org (root@hub.org [216.126.84.1])
|
||
by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id JAA27751
|
||
for <pgman@candle.pha.pa.us>; Wed, 5 Jul 2000 09:04:08 -0400 (EDT)
|
||
Received: from hub.org (majordom@localhost [127.0.0.1])
|
||
by hub.org (8.10.1/8.10.1) with SMTP id e65D44S42069;
|
||
Wed, 5 Jul 2000 09:04:04 -0400 (EDT)
|
||
Received: from turing.csis.gvsu.edu (IDENT:qmailr@csis.gvsu.edu [148.61.162.182])
|
||
by hub.org (8.10.1/8.10.1) with SMTP id e65D2HS35607
|
||
for <pgsql-hackers@postgresql.org>; Wed, 5 Jul 2000 09:02:17 -0400 (EDT)
|
||
Received: (qmail 4436 invoked by uid 0); 5 Jul 2000 13:02:17 -0000
|
||
Received: from eos05.csis.gvsu.edu (eisentrp@148.61.162.105)
|
||
by turing.csis.gvsu.edu with QMQP; 5 Jul 2000 13:02:17 -0000
|
||
From: eisentrp@csis.gvsu.edu
|
||
Date: Wed, 5 Jul 2000 09:02:17 -0400 (EDT)
|
||
Reply-To: Peter Eisentraut <peter_e@gmx.net>
|
||
To: "D'Arcy J.M. Cain" <darcy@druid.net>
|
||
cc: PostgreSQL Development <pgsql-hackers@postgresql.org>
|
||
Subject: Re: [HACKERS] Repair plan for inet and cidr types
|
||
In-Reply-To: <m139egU-000AXpC@druid.net>
|
||
Message-ID: <Pine.LNX.4.21.0007050842080.10677-100000@eos05.csis.gvsu.edu>
|
||
MIME-Version: 1.0
|
||
Content-Type: TEXT/PLAIN; charset=US-ASCII
|
||
X-Mailing-List: pgsql-hackers@postgresql.org
|
||
Precedence: bulk
|
||
Sender: pgsql-hackers-owner@hub.org
|
||
Status: OR
|
||
|
||
On Tue, 4 Jul 2000, D'Arcy J.M. Cain wrote:
|
||
|
||
> I'm not sure I understand why this is necessary. I can see not allowing
|
||
> cidr ==> inet conversions but inet ==> cidr can be done as it is a matter
|
||
> of dropping information - the host part.
|
||
|
||
Automatic casts should not lose information. How would you feel if floats
|
||
were automatically rounded when you store them into int fields? I think
|
||
this is an important principle in any type system.
|
||
|
||
> Then let's define that as the meaning of "inet1 << inet2" i.e. define
|
||
> the << operator between inet types as meaning "tell me if inet1 is in
|
||
> the same network as inet2."
|
||
|
||
Again, let the user say what he wants: inet1 << network(inet2).
|
||
|
||
Also note that "is inet1 in the same network as inet2" is different from
|
||
"is inet1 contained in the network of inet2" (which is what it does now).
|
||
The operator you defined is symmetric (if inet1 is in the same network as
|
||
inet2, then inet2 is also in the same network as inet1), whereas the << is
|
||
antisymmetric. In fact, AFAICT, the operator you defined doesn't exist
|
||
yet, although it perhaps should.
|
||
|
||
|
||
--
|
||
Peter Eisentraut Sernanders vaeg 10:115
|
||
peter_e@gmx.net 75262 Uppsala
|
||
http://yi.org/peter-e/ Sweden
|
||
|
||
|
||
From pgsql-hackers-owner+M4293@hub.org Wed Jul 5 09:50:15 2000
|
||
Received: from hub.org (root@hub.org [216.126.84.1])
|
||
by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id JAA28183
|
||
for <pgman@candle.pha.pa.us>; Wed, 5 Jul 2000 09:50:14 -0400 (EDT)
|
||
Received: from hub.org (majordom@localhost [127.0.0.1])
|
||
by hub.org (8.10.1/8.10.1) with SMTP id e65Do1S55862;
|
||
Wed, 5 Jul 2000 09:50:01 -0400 (EDT)
|
||
Received: from andie.ip23.net (andie.ip23.net [212.83.32.23])
|
||
by hub.org (8.10.1/8.10.1) with ESMTP id e65DmGS51928
|
||
for <pgsql-hackers@PostgreSQL.org>; Wed, 5 Jul 2000 09:48:16 -0400 (EDT)
|
||
Received: from imap1.ip23.net (imap1.ip23.net [212.83.32.35])
|
||
by andie.ip23.net (8.9.3/8.9.3) with ESMTP id PAA33008;
|
||
Wed, 5 Jul 2000 15:48:10 +0200 (CEST)
|
||
Received: from ip23.net (spc.ip23.net [212.83.32.122])
|
||
by imap1.ip23.net (8.9.3/8.9.3) with ESMTP id QAA00989;
|
||
Wed, 5 Jul 2000 16:01:01 +0200 (CEST)
|
||
Message-ID: <39633C99.DD58D11F@ip23.net>
|
||
Date: Wed, 05 Jul 2000 15:48:09 +0200
|
||
From: Sevo Stille <sevo@ip23.net>
|
||
Organization: IP23
|
||
X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.10 i686)
|
||
X-Accept-Language: en, de
|
||
MIME-Version: 1.0
|
||
To: Jakub Bartosz Bielecki <J.B.Bielecki@elka.pw.edu.pl>
|
||
CC: pgsql-hackers@PostgreSQL.org
|
||
Subject: Re: [HACKERS] Re: postgres - development of inet/cidr
|
||
References: <Pine.SOL.4.21.0007051410330.1267-100000@elektron.elka.pw.edu.pl>
|
||
Content-Type: text/plain; charset=us-ascii
|
||
Content-Transfer-Encoding: 7bit
|
||
X-Mailing-List: pgsql-hackers@postgresql.org
|
||
Precedence: bulk
|
||
Sender: pgsql-hackers-owner@hub.org
|
||
Status: OR
|
||
|
||
Jakub Bartosz Bielecki wrote:
|
||
|
||
> > "select '10.0.0.1/27'::cidr << '10.0.0.2/27'::inet;" ERROR
|
||
>
|
||
> Currently it's not an error... There is no way (and no reason) to
|
||
> distinguish between INET and CIDR.
|
||
|
||
Yes, there is. CIDR is defined as the network 10.0.0.1 & /27, while INET
|
||
is defined as host 10.0.0.1 within network 10.0.0.1 & /27. You can do
|
||
almost every network and host calculation both in CIDR and INET, but
|
||
you need implicit knowledge for it. Two columns are necessary to define
|
||
a host and its network in CIDR, and a network cannot be specified
|
||
without a host using INET - except for ugly in-band hacks like using
|
||
10.0.0.0/27 for the network which would prevent you from specifying a
|
||
base address.
|
||
|
||
> Above example is exactly
|
||
> equivalent to:
|
||
> select '10.0.0.0/27'::inet << '10.0.0.2/27'::inet; -- FALSE
|
||
|
||
Nope. If the right hand side is automatically propagated to a network,
|
||
it is true. If not, the above IMHO should better raise an error, as a
|
||
host can never contain a host.
|
||
|
||
> but:
|
||
> select '10.0.0.0/27'::inet <<= '10.0.0.2/27'::inet; -- TRUE
|
||
|
||
Well, you might argue that a host could contain-or-equal a host, but as
|
||
only the equals part could ever be true, that is a redundant operator
|
||
without any meaning beyond equals, and accordingly it should not be
|
||
valid for that case.
|
||
|
||
> > But we need to reach an agreement on the proper
|
||
> > behaviour on greater/smaller comparisons. Should:
|
||
> >
|
||
> > "select '10.0.0.1/27'::inet > '10.0.0.2/27'::cidr;"
|
||
> >
|
||
> > be true or false? Casting to cidr prior to comparison would make it
|
||
> > equivalent to "select '10.0.0.0/27'::cidr > '10.0.0.0/27'::cidr;", which
|
||
> > is false, both networks being equal.
|
||
>
|
||
> It should be (and is!) true... Since second argument is
|
||
> really '10.0.0.0/27'.
|
||
|
||
Yes, but that does not make it any truer. CIDR 10.0.0.0/27 is
|
||
definitively not 10.0.0.0 but [10.0.0.0 .. 10.0.0.31]. A CIDR address is
|
||
never synonymous to a plain host address. You'll see the problem if you
|
||
try to calculate the inverse - any zeroed CIDR address in the entire
|
||
range from 10.0/8 to 10.0.0.0/32 would mask to 10.0.0.0. Accordingly,
|
||
there is no simple answer to a "host bigger/smaller than network"
|
||
question. For many applications, it may be useful to define that to mean
|
||
that the host is smaller than the network bottom address respectively
|
||
bigger than the top address, but any of the other possible views would
|
||
be perfectly legal as well.
|
||
|
||
Sevo
|
||
|
||
--
|
||
sevo@ip23.net
|
||
|
||
From pgsql-hackers-owner+M4354@hub.org Wed Jul 5 16:49:21 2000
|
||
Received: from hub.org (root@hub.org [216.126.84.1])
|
||
by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id QAA17585
|
||
for <pgman@candle.pha.pa.us>; Wed, 5 Jul 2000 16:49:20 -0400 (EDT)
|
||
Received: from hub.org (majordom@localhost [127.0.0.1])
|
||
by hub.org (8.10.1/8.10.1) with SMTP id e65KmdS82556;
|
||
Wed, 5 Jul 2000 16:48:39 -0400 (EDT)
|
||
Received: from druid.net (root@druid.net [216.126.72.98])
|
||
by hub.org (8.10.1/8.10.1) with ESMTP id e65KkqS77601
|
||
for <pgsql-hackers@postgresql.org>; Wed, 5 Jul 2000 16:46:52 -0400 (EDT)
|
||
Received: from localhost (2500 bytes) by druid.net
|
||
via sendmail with P:stdio/R:bind_hosts/T:inet_zone_bind_smtp
|
||
(sender: <darcy>) (ident <darcy> using unix)
|
||
id <m139w4G-000AXpC@druid.net>
|
||
for <pgsql-hackers@postgresql.org>; Wed, 5 Jul 2000 16:46:48 -0400 (EDT)
|
||
(Smail-3.2.0.109 1999-Oct-27 #3 built 2000-Jun-28)
|
||
Message-Id: <m139w4G-000AXpC@druid.net>
|
||
From: darcy@druid.net (D'Arcy J.M. Cain)
|
||
Subject: Re: [HACKERS] Repair plan for inet and cidr types
|
||
In-Reply-To: <Pine.LNX.4.21.0007050842080.10677-100000@eos05.csis.gvsu.edu>
|
||
"from eisentrp@csis.gvsu.edu at Jul 5, 2000 09:02:17 am"
|
||
To: Peter Eisentraut <peter_e@gmx.net>
|
||
Date: Wed, 5 Jul 2000 16:46:48 -0400 (EDT)
|
||
CC: PostgreSQL Development <pgsql-hackers@postgresql.org>
|
||
X-Mailer: ELM [version 2.4ME+ PL78 (25)]
|
||
MIME-Version: 1.0
|
||
Content-Transfer-Encoding: 7bit
|
||
Content-Type: text/plain; charset=US-ASCII
|
||
X-Mailing-List: pgsql-hackers@postgresql.org
|
||
Precedence: bulk
|
||
Sender: pgsql-hackers-owner@hub.org
|
||
Status: OR
|
||
|
||
Thus spake eisentrp@csis.gvsu.edu
|
||
> On Tue, 4 Jul 2000, D'Arcy J.M. Cain wrote:
|
||
> > I'm not sure I understand why this is necessary. I can see not allowing
|
||
> > cidr ==> inet conversions but inet ==> cidr can be done as it is a matter
|
||
> > of dropping information - the host part.
|
||
>
|
||
> Automatic casts should not lose information. How would you feel if floats
|
||
> were automatically rounded when you store them into int fields? I think
|
||
> this is an important principle in any type system.
|
||
|
||
If it was defined well I would have no problem with it.
|
||
|
||
> > Then let's define that as the meaning of "inet1 << inet2" i.e. define
|
||
> > the << operator between inet types as meaning "tell me if inet1 is in
|
||
> > the same network as inet2."
|
||
>
|
||
> Again, let the user say what he wants: inet1 << network(inet2).
|
||
|
||
I think that's what I meant. I'm just saying that inet::cidr should be
|
||
the same as network(inet). Allowing that cast makes a lot of operations
|
||
work intuitively.
|
||
|
||
> Also note that "is inet1 in the same network as inet2" is different from
|
||
> "is inet1 contained in the network of inet2" (which is what it does now).
|
||
|
||
Hmm. It is a subtle difference and I did miss it.
|
||
|
||
> The operator you defined is symmetric (if inet1 is in the same network as
|
||
> inet2, then inet2 is also in the same network as inet1), whereas the << is
|
||
> antisymmetric. In fact, AFAICT, the operator you defined doesn't exist
|
||
> yet, although it perhaps should.
|
||
|
||
I guess what I was really getting at was this.
|
||
|
||
host OP cidr
|
||
|
||
where inet would cast to host on one side and cidr on the other. What
|
||
we have now is
|
||
|
||
cidr OP cidr
|
||
|
||
with both sides casting to cidr. Of course there is no such thing as a host
|
||
type so I don't know how we would cast such a thing.
|
||
|
||
--
|
||
D'Arcy J.M. Cain <darcy@{druid|vex}.net> | Democracy is three wolves
|
||
http://www.druid.net/darcy/ | and a sheep voting on
|
||
+1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner.
|
||
|
||
From pgsql-hackers-owner+M4421@hub.org Thu Jul 6 08:54:47 2000
|
||
Received: from hub.org (root@hub.org [216.126.84.1])
|
||
by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id IAA06169
|
||
for <pgman@candle.pha.pa.us>; Thu, 6 Jul 2000 08:54:46 -0400 (EDT)
|
||
Received: from hub.org (majordom@localhost [127.0.0.1])
|
||
by hub.org (8.10.1/8.10.1) with SMTP id e66CrgS44851;
|
||
Thu, 6 Jul 2000 08:53:42 -0400 (EDT)
|
||
Received: from elektron.elka.pw.edu.pl (root@elektron.elka.pw.edu.pl [148.81.63.249])
|
||
by hub.org (8.10.1/8.10.1) with ESMTP id e66Cr5S44024
|
||
for <pgsql-hackers@PostgreSQL.org>; Thu, 6 Jul 2000 08:53:05 -0400 (EDT)
|
||
Received: from elektron.elka.pw.edu.pl ([148.81.63.249]:64907 "EHLO
|
||
elektron.elka.pw.edu.pl") by elektron.elka.pw.edu.pl with ESMTP
|
||
id <S225243AbQGFMw2>; Thu, 6 Jul 2000 14:52:28 +0200
|
||
Date: Thu, 6 Jul 2000 14:52:17 +0200 (MET DST)
|
||
From: Jakub Bartosz Bielecki <J.B.Bielecki@elka.pw.edu.pl>
|
||
To: Sevo Stille <sevo@ip23.net>
|
||
cc: Jakub Bartosz Bielecki <J.B.Bielecki@elka.pw.edu.pl>,
|
||
pgsql-hackers@PostgreSQL.org
|
||
Subject: Re: [HACKERS] Re: postgres - development of inet/cidr
|
||
In-Reply-To: <39633C99.DD58D11F@ip23.net>
|
||
Message-ID: <Pine.SOL.4.21.0007061354040.20142-100000@elektron.elka.pw.edu.pl>
|
||
MIME-Version: 1.0
|
||
Content-Type: TEXT/PLAIN; charset=US-ASCII
|
||
X-Mailing-List: pgsql-hackers@postgresql.org
|
||
Precedence: bulk
|
||
Sender: pgsql-hackers-owner@hub.org
|
||
Status: OR
|
||
|
||
|
||
|
||
On Wed, 5 Jul 2000, Sevo Stille wrote:
|
||
>
|
||
> > > "select '10.0.0.1/27'::cidr << '10.0.0.2/27'::inet;" ERROR
|
||
> >
|
||
> > Currently it's not an error... There is no way (and no reason) to
|
||
> > distinguish between INET and CIDR.
|
||
>
|
||
> Yes, there is. CIDR is defined as the network 10.0.0.1 & /27, while INET
|
||
> is defined as host 10.0.0.1 within network 10.0.0.1 & /27. You can do
|
||
> almost every network and host calculation both in CIDR and INET, but
|
||
> you need implicit knowledge for it.
|
||
|
||
I was talking about *current* implementation of INET/CIDR (which IMHO
|
||
is very ill).
|
||
There is INET for users that want simply to store IP's and don't care
|
||
about all the technical jargon.
|
||
There is CIDR for advanced users who want to store network data.
|
||
|
||
Currently these 2 types are handled by 1 implementation, moreover despite
|
||
INET netmask and CIDR prefix-length are something completely different,
|
||
both are stored in the same field of inet structure (yuck).
|
||
|
||
At the moment it works fine. But that's only a hack.
|
||
I guess the purpose was to prevent duplication of code... Blah...
|
||
|
||
> > select '10.0.0.0/27'::inet << '10.0.0.2/27'::inet; -- FALSE
|
||
>
|
||
> Nope. If the right hand side is automatically propagated to a network,
|
||
> it is true. If not, the above IMHO should better raise an error, as a
|
||
> host can never contain a host.
|
||
>
|
||
> > select '10.0.0.0/27'::inet <<= '10.0.0.2/27'::inet; -- TRUE
|
||
>
|
||
> Well, you might argue that a host could contain-or-equal a host, but as
|
||
> only the equals part could ever be true, that is a redundant operator
|
||
> without any meaning beyond equals, and accordingly it should not be
|
||
> valid for that case.
|
||
>
|
||
> > > "select '10.0.0.1/27'::inet > '10.0.0.2/27'::cidr;"
|
||
> > It should be (and is!) true... Since second argument is
|
||
> > really '10.0.0.0/27'.
|
||
>
|
||
> Yes, but that does not make it any truer. CIDR 10.0.0.0/27 is
|
||
> definitively not 10.0.0.0 but [10.0.0.0 .. 10.0.0.31].
|
||
|
||
Same as above... You are perfectly right.
|
||
|
||
Everything works until user starts messing with _both_ INET and CIDR
|
||
at the same time.
|
||
|
||
The possible solution is:
|
||
- inhibit cidr-to-inet cast (and maybe also inet-to-cidr, because
|
||
it would throw away netmask),
|
||
- CIDR operators: > = < << >>
|
||
- INET operators: > = < (and why not & | if it would be useful???)
|
||
functions: cidr network(inet); // '10.0.0.0/27'
|
||
text host(inet); // '10.0.0.1'
|
||
int masklen(inet); // 27
|
||
- write an usable manual.
|
||
|
||
Comments?
|
||
I *might* work on it if I find some spare time. But it's unlikely :(
|
||
|
||
|
||
From pgsql-hackers-owner+M4503@hub.org Fri Jul 7 12:11:37 2000
|
||
Received: from hub.org (root@hub.org [216.126.84.1])
|
||
by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id MAA26802
|
||
for <pgman@candle.pha.pa.us>; Fri, 7 Jul 2000 12:11:36 -0400 (EDT)
|
||
Received: from hub.org (majordom@localhost [127.0.0.1])
|
||
by hub.org (8.10.1/8.10.1) with SMTP id e67GAgW67823;
|
||
Fri, 7 Jul 2000 12:10:42 -0400 (EDT)
|
||
Received: from merganser.its.uu.se (merganser.its.uu.se [130.238.6.236])
|
||
by hub.org (8.10.1/8.10.1) with ESMTP id e67G9qW66262
|
||
for <pgsql-hackers@postgresql.org>; Fri, 7 Jul 2000 12:09:52 -0400 (EDT)
|
||
Received: from regulus.student.UU.SE ([130.238.5.2]:53522 "EHLO
|
||
regulus.its.uu.se") by merganser.its.uu.se with ESMTP
|
||
id <S493726AbQGGQJO>; Fri, 7 Jul 2000 18:09:14 +0200
|
||
Received: from peter (helo=localhost)
|
||
by regulus.its.uu.se with local-esmtp (Exim 3.02 #2)
|
||
id 13Aani-0003A6-00; Fri, 07 Jul 2000 18:16:26 +0200
|
||
Date: Fri, 7 Jul 2000 18:16:26 +0200 (CEST)
|
||
From: Peter Eisentraut <peter_e@gmx.net>
|
||
To: "D'Arcy J.M. Cain" <darcy@druid.net>
|
||
cc: PostgreSQL Development <pgsql-hackers@postgresql.org>
|
||
Subject: Re: [HACKERS] Repair plan for inet and cidr types
|
||
In-Reply-To: <m139w4G-000AXpC@druid.net>
|
||
Message-ID: <Pine.LNX.4.21.0007070156410.4191-100000@localhost.localdomain>
|
||
MIME-Version: 1.0
|
||
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
|
||
Content-Transfer-Encoding: 8BIT
|
||
X-Mailing-List: pgsql-hackers@postgresql.org
|
||
Precedence: bulk
|
||
Sender: pgsql-hackers-owner@hub.org
|
||
Status: OR
|
||
|
||
D'Arcy J.M. Cain writes:
|
||
|
||
> > Automatic casts should not lose information. How would you feel if floats
|
||
> > were automatically rounded when you store them into int fields? I think
|
||
> > this is an important principle in any type system.
|
||
>
|
||
> If it was defined well I would have no problem with it.
|
||
|
||
That is certainly not how type systems operate anywhere.
|
||
|
||
> I guess what I was really getting at was this.
|
||
>
|
||
> host OP cidr
|
||
>
|
||
> where inet would cast to host on one side and cidr on the other. What
|
||
> we have now is
|
||
>
|
||
> cidr OP cidr
|
||
>
|
||
> with both sides casting to cidr. Of course there is no such thing as a host
|
||
> type so I don't know how we would cast such a thing.
|
||
|
||
I think that while the implicit casting could sometimes be convenient,
|
||
it's also a source of confusion. Consider the statement
|
||
|
||
select '10.0.0.3'::cidr < '10.0.0.2'::inet; => f
|
||
|
||
This cannot possibly make sense on closer inspection. Firstly, it's
|
||
semantic nonsense, you cannot order a network and a host. Secondly, it's
|
||
also wrong. According to the documentation, the '10.0.0.3'::cidr should be
|
||
converted to '10/8' internally. Then one of two things could have happened
|
||
here: 1) cidr was implicitly converted to inet and '10.0.0.3' is taken to
|
||
be a host, which is completely wrong. Or 2) inet was converted to cidr.
|
||
But then we're looking at '10/8' < '10.0.0.2/32', which should be true.
|
||
|
||
See also
|
||
|
||
select '10.0.0.2'::cidr = '10.0.0.2'::inet; => t
|
||
|
||
which is wrong for similar reasons.
|
||
|
||
|
||
Then let's look at the << family of operators.
|
||
|
||
select '10.0.0.2'::cidr >> '10.0.0.2'::inet; => f
|
||
|
||
Again, there are two ways this could currently be resolved:
|
||
|
||
'10/8'::cidr >> '10.0.0.2/32'::cidr which does return true
|
||
or
|
||
'10.0.0.2'::inet >> '10.0.0.2'::inet
|
||
which doesn't make any sense.
|
||
|
||
On closer inspection, the inet << cidr case is completely misbehaving:
|
||
|
||
select '10.0.0.5/8'::inet << '10.0.0.0/16'::cidr; => f
|
||
select '10.0.0.5/24'::inet << '10.0.0.0/16'::cidr; => t
|
||
|
||
This is not what I'd expect.
|
||
|
||
Concretely, the cases
|
||
inet << cidr
|
||
cidr << cidr
|
||
are not the same:
|
||
|
||
'10.0.0.5/8'::inet << '10.0.0.0/16'::cidr
|
||
should be true
|
||
|
||
'10.0.0.5/8'::cidr << '10.0.0.0/16'::cidr
|
||
should be false, if you allow the left-side value in at all, which I
|
||
wouldn't.
|
||
|
||
What this tells me is that the cast from inet to cidr is not well-defined
|
||
in the mathematical sense, and therefore no implicit casting should be
|
||
allowed.
|
||
|
||
So the bottom line here is that these two types are, while from a related
|
||
domain, different, and the user should be the one that controls when and
|
||
how they are mixed together.
|
||
|
||
|
||
--
|
||
Peter Eisentraut Sernanders v<>g 10:115
|
||
peter_e@gmx.net 75262 Uppsala
|
||
http://yi.org/peter-e/ Sweden
|
||
|
||
|
||
From pgsql-hackers-owner+M5242@hub.org Sun Jul 23 10:01:45 2000
|
||
Received: from hub.org (root@hub.org [216.126.84.1])
|
||
by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id KAA21261
|
||
for <pgman@candle.pha.pa.us>; Sun, 23 Jul 2000 10:01:44 -0400 (EDT)
|
||
Received: from hub.org (majordom@localhost [127.0.0.1])
|
||
by hub.org (8.10.1/8.10.1) with SMTP id e6NE1Th91342;
|
||
Sun, 23 Jul 2000 10:01:29 -0400 (EDT)
|
||
Received: from lerami.lerctr.org (lerami.lerctr.org [207.158.72.11])
|
||
by hub.org (8.10.1/8.10.1) with ESMTP id e6NE10h91172
|
||
for <pgsql-hackers@hub.org>; Sun, 23 Jul 2000 10:01:00 -0400 (EDT)
|
||
Received: (from ler@localhost)
|
||
by lerami.lerctr.org (8.10.1/8.10.1/20000715) id e6NE0w219946
|
||
for pgsql-hackers@hub.org; Sun, 23 Jul 2000 09:00:58 -0500 (CDT)
|
||
From: Larry Rosenman <ler@lerctr.org>
|
||
Message-Id: <200007231400.e6NE0w219946@lerami.lerctr.org>
|
||
Subject: [HACKERS] INET/CIDR types
|
||
To: pgsql-hackers@hub.org
|
||
Date: Sun, 23 Jul 2000 09:00:57 -0500 (CDT)
|
||
X-Mailer: ELM [version 2.4ME+ PL79 (25)]
|
||
MIME-Version: 1.0
|
||
Content-Transfer-Encoding: 7bit
|
||
Content-Type: text/plain; charset=US-ASCII
|
||
X-Mailing-List: pgsql-hackers@postgresql.org
|
||
Precedence: bulk
|
||
Sender: pgsql-hackers-owner@hub.org
|
||
Status: OR
|
||
|
||
I noticed a discussion on this list about a re-do of the INET/CIDR
|
||
types. I was wondering if there was ANY way at all to add
|
||
an output function that ALWAYS returns all 4 octets of an INET or CIDR
|
||
type with and without the /netmask?
|
||
|
||
I'm writing a IP Allocation/Tracking app for the ISP I work for, and
|
||
find the current output format causes confusion for the less
|
||
technical types.
|
||
|
||
Larry Rosenman
|
||
--
|
||
Larry Rosenman http://www.lerctr.org/~ler
|
||
Phone: +1 972-414-9812 (voice) Internet: ler@lerctr.org
|
||
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
|
||
|
||
From pgsql-hackers-owner+M5264@hub.org Mon Jul 24 10:34:39 2000
|
||
Received: from hub.org (root@hub.org [216.126.84.1])
|
||
by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id KAA09676
|
||
for <pgman@candle.pha.pa.us>; Mon, 24 Jul 2000 10:34:38 -0400 (EDT)
|
||
Received: from hub.org (majordom@localhost [127.0.0.1])
|
||
by hub.org (8.10.1/8.10.1) with SMTP id e6OEXZh83378;
|
||
Mon, 24 Jul 2000 10:33:35 -0400 (EDT)
|
||
Received: from druid.net (root@druid.net [216.126.72.98])
|
||
by hub.org (8.10.1/8.10.1) with ESMTP id e6OEXGh83201
|
||
for <pgsql-hackers@hub.org>; Mon, 24 Jul 2000 10:33:16 -0400 (EDT)
|
||
Received: from localhost (1444 bytes) by druid.net
|
||
via sendmail with P:stdio/R:bind_hosts/T:inet_zone_bind_smtp
|
||
(sender: <darcy>) (ident <darcy> using unix)
|
||
id <m13GjIB-000AXgC@druid.net>
|
||
for <pgsql-hackers@hub.org>; Mon, 24 Jul 2000 10:33:15 -0400 (EDT)
|
||
(Smail-3.2.0.109 1999-Oct-27 #3 built 2000-Jun-28)
|
||
Message-Id: <m13GjIB-000AXgC@druid.net>
|
||
From: darcy@druid.net (D'Arcy J.M. Cain)
|
||
Subject: Re: [HACKERS] INET/CIDR types
|
||
In-Reply-To: <200007231400.e6NE0w219946@lerami.lerctr.org> "from Larry Rosenman
|
||
at Jul 23, 2000 09:00:57 am"
|
||
To: Larry Rosenman <ler@lerctr.org>
|
||
Date: Mon, 24 Jul 2000 10:33:14 -0400 (EDT)
|
||
CC: pgsql-hackers@hub.org
|
||
Reply-To: pgsql-hackers@hub.org
|
||
X-Mailer: ELM [version 2.4ME+ PL78 (25)]
|
||
MIME-Version: 1.0
|
||
Content-Transfer-Encoding: 7bit
|
||
Content-Type: text/plain; charset=US-ASCII
|
||
X-Mailing-List: pgsql-hackers@postgresql.org
|
||
Precedence: bulk
|
||
Sender: pgsql-hackers-owner@hub.org
|
||
Status: OR
|
||
|
||
Thus spake Larry Rosenman
|
||
> I noticed a discussion on this list about a re-do of the INET/CIDR
|
||
> types. I was wondering if there was ANY way at all to add
|
||
> an output function that ALWAYS returns all 4 octets of an INET or CIDR
|
||
> type with and without the /netmask?
|
||
>
|
||
> I'm writing a IP Allocation/Tracking app for the ISP I work for, and
|
||
> find the current output format causes confusion for the less
|
||
> technical types.
|
||
|
||
The host() function does this for the INET type. It doesn't work for
|
||
the CIDR type (it throws an error) because CIDR doesn't have a host
|
||
part per se.
|
||
|
||
darcy=> select '1.2.0.0/23'::inet;
|
||
?column?
|
||
--------
|
||
1.2.0/23
|
||
(1 row)
|
||
|
||
darcy=> select host('1.2.0.0/23'::inet);
|
||
host
|
||
-------
|
||
1.2.0.0
|
||
(1 row)
|
||
|
||
--
|
||
D'Arcy J.M. Cain <darcy@{druid|vex}.net> | Democracy is three wolves
|
||
http://www.druid.net/darcy/ | and a sheep voting on
|
||
+1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner.
|
||
|
||
From pgsql-hackers-owner+M5265@hub.org Mon Jul 24 10:43:14 2000
|
||
Received: from hub.org (root@hub.org [216.126.84.1])
|
||
by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id KAA09722
|
||
for <pgman@candle.pha.pa.us>; Mon, 24 Jul 2000 10:43:13 -0400 (EDT)
|
||
Received: from hub.org (majordom@localhost [127.0.0.1])
|
||
by hub.org (8.10.1/8.10.1) with SMTP id e6OEfLh86364;
|
||
Mon, 24 Jul 2000 10:41:21 -0400 (EDT)
|
||
Received: from lerami.lerctr.org (lerami.lerctr.org [207.158.72.11])
|
||
by hub.org (8.10.1/8.10.1) with ESMTP id e6OEf6h86190
|
||
for <pgsql-hackers@hub.org>; Mon, 24 Jul 2000 10:41:06 -0400 (EDT)
|
||
Received: (from ler@localhost)
|
||
by lerami.lerctr.org (8.10.1/8.10.1/20000715) id e6OEf5D12433;
|
||
Mon, 24 Jul 2000 09:41:05 -0500 (CDT)
|
||
From: Larry Rosenman <ler@lerctr.org>
|
||
Message-Id: <200007241441.e6OEf5D12433@lerami.lerctr.org>
|
||
Subject: Re: [HACKERS] INET/CIDR types
|
||
In-Reply-To: <m13GjIB-000AXgC@druid.net> "from darcy@druid.net at Jul 24, 2000
|
||
10:33:14 am"
|
||
To: pgsql-hackers@hub.org
|
||
Date: Mon, 24 Jul 2000 09:41:05 -0500 (CDT)
|
||
CC: Larry Rosenman <ler@lerctr.org>
|
||
X-Mailer: ELM [version 2.4ME+ PL79 (25)]
|
||
MIME-Version: 1.0
|
||
Content-Transfer-Encoding: 7bit
|
||
Content-Type: text/plain; charset=US-ASCII
|
||
X-Mailing-List: pgsql-hackers@postgresql.org
|
||
Precedence: bulk
|
||
Sender: pgsql-hackers-owner@hub.org
|
||
Status: OR
|
||
|
||
The bad news is that I'm tracking CIDR blocks.
|
||
|
||
If I could get a network() function to return essentially
|
||
host()::inet for CIDR's that would work.
|
||
|
||
Larry
|
||
> Thus spake Larry Rosenman
|
||
> > I noticed a discussion on this list about a re-do of the INET/CIDR
|
||
> > types. I was wondering if there was ANY way at all to add
|
||
> > an output function that ALWAYS returns all 4 octets of an INET or CIDR
|
||
> > type with and without the /netmask?
|
||
> >
|
||
> > I'm writing a IP Allocation/Tracking app for the ISP I work for, and
|
||
> > find the current output format causes confusion for the less
|
||
> > technical types.
|
||
>
|
||
> The host() function does this for the INET type. It doesn't work for
|
||
> the CIDR type (it throws an error) because CIDR doesn't have a host
|
||
> part per se.
|
||
>
|
||
> darcy=> select '1.2.0.0/23'::inet;
|
||
> ?column?
|
||
> --------
|
||
> 1.2.0/23
|
||
> (1 row)
|
||
>
|
||
> darcy=> select host('1.2.0.0/23'::inet);
|
||
> host
|
||
> -------
|
||
> 1.2.0.0
|
||
> (1 row)
|
||
>
|
||
> --
|
||
> D'Arcy J.M. Cain <darcy@{druid|vex}.net> | Democracy is three wolves
|
||
> http://www.druid.net/darcy/ | and a sheep voting on
|
||
> +1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner.
|
||
|
||
|
||
--
|
||
Larry Rosenman http://www.lerctr.org/~ler
|
||
Phone: +1 972-414-9812 (voice) Internet: ler@lerctr.org
|
||
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
|
||
|
||
From pgsql-hackers-owner+M5270@hub.org Mon Jul 24 15:17:30 2000
|
||
Received: from hub.org (root@hub.org [216.126.84.1])
|
||
by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id PAA11467
|
||
for <pgman@candle.pha.pa.us>; Mon, 24 Jul 2000 15:17:29 -0400 (EDT)
|
||
Received: from hub.org (majordom@localhost [127.0.0.1])
|
||
by hub.org (8.10.1/8.10.1) with SMTP id e6OJHEh72992;
|
||
Mon, 24 Jul 2000 15:17:14 -0400 (EDT)
|
||
Received: from druid.net (root@druid.net [216.126.72.98])
|
||
by hub.org (8.10.1/8.10.1) with ESMTP id e6OJF3h71969
|
||
for <pgsql-hackers@hub.org>; Mon, 24 Jul 2000 15:15:04 -0400 (EDT)
|
||
Received: from localhost (1687 bytes) by druid.net
|
||
via sendmail with P:stdio/R:bind_hosts/T:inet_zone_bind_smtp
|
||
(sender: <darcy>) (ident <darcy> using unix)
|
||
id <m13Gngs-000AXeC@druid.net>
|
||
for <pgsql-hackers@hub.org>; Mon, 24 Jul 2000 15:15:02 -0400 (EDT)
|
||
(Smail-3.2.0.109 1999-Oct-27 #3 built 2000-Jun-28)
|
||
Message-Id: <m13Gngs-000AXeC@druid.net>
|
||
From: darcy@druid.net (D'Arcy J.M. Cain)
|
||
Subject: Re: [HACKERS] INET/CIDR types
|
||
In-Reply-To: <200007241441.e6OEf5D12433@lerami.lerctr.org> "from Larry Rosenman
|
||
at Jul 24, 2000 09:41:05 am"
|
||
To: Larry Rosenman <ler@lerctr.org>
|
||
Date: Mon, 24 Jul 2000 15:15:01 -0400 (EDT)
|
||
CC: pgsql-hackers@hub.org
|
||
Reply-To: pgsql-hackers@hub.org
|
||
X-Mailer: ELM [version 2.4ME+ PL78 (25)]
|
||
MIME-Version: 1.0
|
||
Content-Transfer-Encoding: 7bit
|
||
Content-Type: text/plain; charset=US-ASCII
|
||
X-Mailing-List: pgsql-hackers@postgresql.org
|
||
Precedence: bulk
|
||
Sender: pgsql-hackers-owner@hub.org
|
||
Status: OR
|
||
|
||
Thus spake Larry Rosenman
|
||
> The bad news is that I'm tracking CIDR blocks.
|
||
|
||
Then there is no host part. I would argue that if someone is getting
|
||
confused with the current output then perhaps they shouldn't be dealing
|
||
with client networks.
|
||
|
||
> If I could get a network() function to return essentially
|
||
> host()::inet for CIDR's that would work.
|
||
|
||
There is a network function. It returns the network.
|
||
|
||
darcy=> select network('1.2.0.0/23'::cidr);
|
||
network
|
||
--------
|
||
1.2.0/23
|
||
(1 row)
|
||
|
||
A lot of work went into these types to make them correct. I don't think
|
||
we should be undermining that to allow people to work with incorrect
|
||
assumptions. If you want Micro$oft you know where to find it.
|
||
|
||
If you really must do this then store your blocks in the INET type. It
|
||
pretty much does what you want but doesn't try to pretend to be a CIDR.
|
||
|
||
|
||
Hmmm. I just noticed this.
|
||
|
||
darcy=> select '1.2.0.1/23'::cidr;
|
||
?column?
|
||
--------
|
||
1.2.0/23
|
||
(1 row)
|
||
|
||
Shouldn't that throw an error?
|
||
|
||
--
|
||
D'Arcy J.M. Cain <darcy@{druid|vex}.net> | Democracy is three wolves
|
||
http://www.druid.net/darcy/ | and a sheep voting on
|
||
+1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner.
|
||
|
||
From pgsql-hackers-owner+M5271@hub.org Mon Jul 24 15:28:37 2000
|
||
Received: from hub.org (root@hub.org [216.126.84.1])
|
||
by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id PAA11521
|
||
for <pgman@candle.pha.pa.us>; Mon, 24 Jul 2000 15:28:36 -0400 (EDT)
|
||
Received: from hub.org (majordom@localhost [127.0.0.1])
|
||
by hub.org (8.10.1/8.10.1) with SMTP id e6OJSMh77820;
|
||
Mon, 24 Jul 2000 15:28:22 -0400 (EDT)
|
||
Received: from lerami.lerctr.org (lerami.lerctr.org [207.158.72.11])
|
||
by hub.org (8.10.1/8.10.1) with ESMTP id e6OJQhh76867
|
||
for <pgsql-hackers@hub.org>; Mon, 24 Jul 2000 15:26:43 -0400 (EDT)
|
||
Received: from lerdesk (ler-desk.iadfw.net [206.66.13.18])
|
||
by lerami.lerctr.org (8.10.1/8.10.1/20000715) with SMTP id e6OJQcc24312;
|
||
Mon, 24 Jul 2000 14:26:38 -0500 (CDT)
|
||
From: "Larry Rosenman" <ler@lerctr.org>
|
||
To: <pgsql-hackers@hub.org>, "Larry Rosenman" <ler@lerctr.org>
|
||
Subject: RE: [HACKERS] INET/CIDR types
|
||
Date: Mon, 24 Jul 2000 14:26:37 -0500
|
||
Message-ID: <NCBBKBDOOHHEJCJHLLPAMELAHIAA.ler@lerctr.org>
|
||
MIME-Version: 1.0
|
||
Content-Type: text/plain;
|
||
charset="iso-8859-1"
|
||
Content-Transfer-Encoding: 7bit
|
||
X-Priority: 3 (Normal)
|
||
X-MSMail-Priority: Normal
|
||
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
|
||
X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400
|
||
Importance: Normal
|
||
In-Reply-To: <m13Gngs-000AXeC@druid.net>
|
||
X-Mailing-List: pgsql-hackers@postgresql.org
|
||
Precedence: bulk
|
||
Sender: pgsql-hackers-owner@hub.org
|
||
Status: OR
|
||
|
||
The problem is NON-TECHNICAL people will be getting the output,
|
||
and they expect 4 octet output.
|
||
|
||
I really think that we should have a way to coerce a CIDR to
|
||
an INET, and then allow host().
|
||
|
||
Remember that I am dealing with $10/hour clerks.
|
||
|
||
I really don't get the hostility to changing the OUTPUT format...
|
||
|
||
Larry Rosenman
|
||
|
||
-----Original Message-----
|
||
From: D'Arcy J.M. Cain [mailto:darcy@druid.net]
|
||
Sent: Monday, July 24, 2000 2:15 PM
|
||
To: Larry Rosenman
|
||
Cc: pgsql-hackers@hub.org
|
||
Subject: Re: [HACKERS] INET/CIDR types
|
||
|
||
|
||
Thus spake Larry Rosenman
|
||
> The bad news is that I'm tracking CIDR blocks.
|
||
|
||
Then there is no host part. I would argue that if someone is getting
|
||
confused with the current output then perhaps they shouldn't be dealing
|
||
with client networks.
|
||
|
||
> If I could get a network() function to return essentially
|
||
> host()::inet for CIDR's that would work.
|
||
|
||
There is a network function. It returns the network.
|
||
|
||
darcy=> select network('1.2.0.0/23'::cidr);
|
||
network
|
||
--------
|
||
1.2.0/23
|
||
(1 row)
|
||
|
||
A lot of work went into these types to make them correct. I don't think
|
||
we should be undermining that to allow people to work with incorrect
|
||
assumptions. If you want Micro$oft you know where to find it.
|
||
|
||
If you really must do this then store your blocks in the INET type. It
|
||
pretty much does what you want but doesn't try to pretend to be a CIDR.
|
||
|
||
|
||
Hmmm. I just noticed this.
|
||
|
||
darcy=> select '1.2.0.1/23'::cidr;
|
||
?column?
|
||
--------
|
||
1.2.0/23
|
||
(1 row)
|
||
|
||
Shouldn't that throw an error?
|
||
|
||
--
|
||
D'Arcy J.M. Cain <darcy@{druid|vex}.net> | Democracy is three wolves
|
||
http://www.druid.net/darcy/ | and a sheep voting on
|
||
+1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner.
|
||
|
||
From pgsql-hackers-owner+M5272@hub.org Mon Jul 24 15:35:28 2000
|
||
Received: from hub.org (root@hub.org [216.126.84.1])
|
||
by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id PAA11554
|
||
for <pgman@candle.pha.pa.us>; Mon, 24 Jul 2000 15:35:28 -0400 (EDT)
|
||
Received: from hub.org (majordom@localhost [127.0.0.1])
|
||
by hub.org (8.10.1/8.10.1) with SMTP id e6OJZFh80569;
|
||
Mon, 24 Jul 2000 15:35:16 -0400 (EDT)
|
||
Received: from smtp.pacifier.com (comet.pacifier.com [199.2.117.155])
|
||
by hub.org (8.10.1/8.10.1) with ESMTP id e6OJXgh80113
|
||
for <pgsql-hackers@hub.org>; Mon, 24 Jul 2000 15:33:42 -0400 (EDT)
|
||
Received: from desktop (dsl-dhogaza.pacifier.net [207.202.226.68])
|
||
by smtp.pacifier.com (8.9.3/8.9.3pop) with SMTP id MAA07579;
|
||
Mon, 24 Jul 2000 12:33:32 -0700 (PDT)
|
||
Message-Id: <3.0.1.32.20000724123008.01189db0@mail.pacifier.com>
|
||
X-Sender: dhogaza@mail.pacifier.com
|
||
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
|
||
Date: Mon, 24 Jul 2000 12:30:08 -0700
|
||
To: "Larry Rosenman" <ler@lerctr.org>, <pgsql-hackers@hub.org>,
|
||
"Larry Rosenman" <ler@lerctr.org>
|
||
From: Don Baccus <dhogaza@pacifier.com>
|
||
Subject: RE: [HACKERS] INET/CIDR types
|
||
In-Reply-To: <NCBBKBDOOHHEJCJHLLPAMELAHIAA.ler@lerctr.org>
|
||
References: <m13Gngs-000AXeC@druid.net>
|
||
Mime-Version: 1.0
|
||
Content-Type: text/plain; charset="us-ascii"
|
||
X-Mailing-List: pgsql-hackers@postgresql.org
|
||
Precedence: bulk
|
||
Sender: pgsql-hackers-owner@hub.org
|
||
Status: OR
|
||
|
||
At 02:26 PM 7/24/00 -0500, Larry Rosenman wrote:
|
||
>The problem is NON-TECHNICAL people will be getting the output,
|
||
>and they expect 4 octet output.
|
||
>
|
||
>I really think that we should have a way to coerce a CIDR to
|
||
>an INET, and then allow host().
|
||
>
|
||
>Remember that I am dealing with $10/hour clerks.
|
||
>
|
||
>I really don't get the hostility to changing the OUTPUT format...
|
||
|
||
Are these $10/hour clerks typing in SQL to psql? Strange ...
|
||
|
||
If not, formatting issues like this can easily be broken (or fixed,
|
||
according to your POV) by your application client.
|
||
|
||
|
||
|
||
- Don Baccus, Portland OR <dhogaza@pacifier.com>
|
||
Nature photos, on-line guides, Pacific Northwest
|
||
Rare Bird Alert Service and other goodies at
|
||
http://donb.photo.net.
|
||
|
||
From pgsql-hackers-owner+M5273@hub.org Mon Jul 24 15:38:46 2000
|
||
Received: from hub.org (root@hub.org [216.126.84.1])
|
||
by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id PAA11571
|
||
for <pgman@candle.pha.pa.us>; Mon, 24 Jul 2000 15:38:45 -0400 (EDT)
|
||
Received: from hub.org (majordom@localhost [127.0.0.1])
|
||
by hub.org (8.10.1/8.10.1) with SMTP id e6OJcPh81593;
|
||
Mon, 24 Jul 2000 15:38:25 -0400 (EDT)
|
||
Received: from lerami.lerctr.org (lerami.lerctr.org [207.158.72.11])
|
||
by hub.org (8.10.1/8.10.1) with ESMTP id e6OJanh80997
|
||
for <pgsql-hackers@hub.org>; Mon, 24 Jul 2000 15:36:49 -0400 (EDT)
|
||
Received: from lerdesk (ler-desk.iadfw.net [206.66.13.18])
|
||
by lerami.lerctr.org (8.10.1/8.10.1/20000715) with SMTP id e6OJajc24698;
|
||
Mon, 24 Jul 2000 14:36:45 -0500 (CDT)
|
||
From: "Larry Rosenman" <ler@lerctr.org>
|
||
To: "Don Baccus" <dhogaza@pacifier.com>, "Larry Rosenman" <ler@lerctr.org>,
|
||
<pgsql-hackers@hub.org>, "Larry Rosenman" <ler@lerctr.org>
|
||
Subject: RE: [HACKERS] INET/CIDR types
|
||
Date: Mon, 24 Jul 2000 14:36:44 -0500
|
||
Message-ID: <NCBBKBDOOHHEJCJHLLPACELCHIAA.ler@lerctr.org>
|
||
MIME-Version: 1.0
|
||
Content-Type: text/plain;
|
||
charset="iso-8859-1"
|
||
Content-Transfer-Encoding: 7bit
|
||
X-Priority: 3 (Normal)
|
||
X-MSMail-Priority: Normal
|
||
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
|
||
X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400
|
||
Importance: Normal
|
||
In-Reply-To: <3.0.1.32.20000724123008.01189db0@mail.pacifier.com>
|
||
X-Mailing-List: pgsql-hackers@postgresql.org
|
||
Precedence: bulk
|
||
Sender: pgsql-hackers-owner@hub.org
|
||
Status: OR
|
||
|
||
I was hoping to have some niceties out of the SQL retrieve to print directly
|
||
in PHP, and not have to massage it.
|
||
|
||
Why is there such animosity to printing out all 4 octets in some function
|
||
somewhere for a CIDR block?
|
||
|
||
Larry
|
||
|
||
-----Original Message-----
|
||
From: Don Baccus [mailto:dhogaza@pacifier.com]
|
||
Sent: Monday, July 24, 2000 2:30 PM
|
||
To: Larry Rosenman; pgsql-hackers@hub.org; Larry Rosenman
|
||
Subject: RE: [HACKERS] INET/CIDR types
|
||
|
||
|
||
At 02:26 PM 7/24/00 -0500, Larry Rosenman wrote:
|
||
>The problem is NON-TECHNICAL people will be getting the output,
|
||
>and they expect 4 octet output.
|
||
>
|
||
>I really think that we should have a way to coerce a CIDR to
|
||
>an INET, and then allow host().
|
||
>
|
||
>Remember that I am dealing with $10/hour clerks.
|
||
>
|
||
>I really don't get the hostility to changing the OUTPUT format...
|
||
|
||
Are these $10/hour clerks typing in SQL to psql? Strange ...
|
||
|
||
If not, formatting issues like this can easily be broken (or fixed,
|
||
according to your POV) by your application client.
|
||
|
||
|
||
|
||
- Don Baccus, Portland OR <dhogaza@pacifier.com>
|
||
Nature photos, on-line guides, Pacific Northwest
|
||
Rare Bird Alert Service and other goodies at
|
||
http://donb.photo.net.
|
||
|
||
From pgsql-hackers-owner+M5274@hub.org Mon Jul 24 16:19:47 2000
|
||
Received: from hub.org (root@hub.org [216.126.84.1])
|
||
by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id QAA11771
|
||
for <pgman@candle.pha.pa.us>; Mon, 24 Jul 2000 16:19:46 -0400 (EDT)
|
||
Received: from hub.org (majordom@localhost [127.0.0.1])
|
||
by hub.org (8.10.1/8.10.1) with SMTP id e6OKJRh99659;
|
||
Mon, 24 Jul 2000 16:19:28 -0400 (EDT)
|
||
Received: from druid.net (root@druid.net [216.126.72.98])
|
||
by hub.org (8.10.1/8.10.1) with ESMTP id e6OKHbh98841
|
||
for <pgsql-hackers@hub.org>; Mon, 24 Jul 2000 16:17:37 -0400 (EDT)
|
||
Received: from localhost (1546 bytes) by druid.net
|
||
via sendmail with P:stdio/R:bind_hosts/T:inet_zone_bind_smtp
|
||
(sender: <darcy>) (ident <darcy> using unix)
|
||
id <m13GofQ-000AX1C@druid.net>
|
||
for <pgsql-hackers@hub.org>; Mon, 24 Jul 2000 16:17:36 -0400 (EDT)
|
||
(Smail-3.2.0.109 1999-Oct-27 #3 built 2000-Jun-28)
|
||
Message-Id: <m13GofQ-000AX1C@druid.net>
|
||
From: darcy@druid.net (D'Arcy J.M. Cain)
|
||
Subject: Re: [HACKERS] INET/CIDR types
|
||
In-Reply-To: <NCBBKBDOOHHEJCJHLLPACELCHIAA.ler@lerctr.org> "from Larry Rosenman
|
||
at Jul 24, 2000 02:36:44 pm"
|
||
To: Larry Rosenman <ler@lerctr.org>
|
||
Date: Mon, 24 Jul 2000 16:17:36 -0400 (EDT)
|
||
CC: Don Baccus <dhogaza@pacifier.com>, pgsql-hackers@hub.org
|
||
Reply-To: pgsql-hackers@hub.org
|
||
X-Mailer: ELM [version 2.4ME+ PL78 (25)]
|
||
MIME-Version: 1.0
|
||
Content-Transfer-Encoding: 7bit
|
||
Content-Type: text/plain; charset=US-ASCII
|
||
X-Mailing-List: pgsql-hackers@postgresql.org
|
||
Precedence: bulk
|
||
Sender: pgsql-hackers-owner@hub.org
|
||
Status: OR
|
||
|
||
Thus spake Larry Rosenman
|
||
> I was hoping to have some niceties out of the SQL retrieve to print directly
|
||
> in PHP, and not have to massage it.
|
||
>
|
||
> Why is there such animosity to printing out all 4 octets in some function
|
||
> somewhere for a CIDR block?
|
||
|
||
You keep saying "hostility" as if we are ganging up against you. Believe
|
||
me, I have no animosity towards you and I am sure no one else has either.
|
||
We are resisting the change you want simply because it would violate the
|
||
RFC which we agreed to follow when we created the types.
|
||
|
||
If you think this is hostile, you will probably think that the original
|
||
discussions in the archives are nuclear war :-). If you would like to
|
||
look it over make sure to set aside a lot of time. We spent a long time
|
||
hashing this out.
|
||
|
||
--
|
||
D'Arcy J.M. Cain <darcy@{druid|vex}.net> | Democracy is three wolves
|
||
http://www.druid.net/darcy/ | and a sheep voting on
|
||
+1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner.
|
||
|
||
From pgsql-hackers-owner+M5275@hub.org Mon Jul 24 16:29:30 2000
|
||
Received: from hub.org (root@hub.org [216.126.84.1])
|
||
by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id QAA11819
|
||
for <pgman@candle.pha.pa.us>; Mon, 24 Jul 2000 16:29:28 -0400 (EDT)
|
||
Received: from hub.org (majordom@localhost [127.0.0.1])
|
||
by hub.org (8.10.1/8.10.1) with SMTP id e6OKT6h02534;
|
||
Mon, 24 Jul 2000 16:29:06 -0400 (EDT)
|
||
Received: from lerami.lerctr.org (lerami.lerctr.org [207.158.72.11])
|
||
by hub.org (8.10.1/8.10.1) with ESMTP id e6OKRUh02012
|
||
for <pgsql-hackers@hub.org>; Mon, 24 Jul 2000 16:27:30 -0400 (EDT)
|
||
Received: from lerdesk (ler-desk.iadfw.net [206.66.13.18])
|
||
by lerami.lerctr.org (8.10.1/8.10.1/20000715) with SMTP id e6OKRPc26861;
|
||
Mon, 24 Jul 2000 15:27:25 -0500 (CDT)
|
||
From: "Larry Rosenman" <ler@lerctr.org>
|
||
To: <pgsql-hackers@hub.org>, "Larry Rosenman" <ler@lerctr.org>
|
||
Cc: "Don Baccus" <dhogaza@pacifier.com>
|
||
Subject: RE: [HACKERS] INET/CIDR types
|
||
Date: Mon, 24 Jul 2000 15:27:24 -0500
|
||
Message-ID: <NCBBKBDOOHHEJCJHLLPAAELHHIAA.ler@lerctr.org>
|
||
MIME-Version: 1.0
|
||
Content-Type: text/plain;
|
||
charset="iso-8859-1"
|
||
Content-Transfer-Encoding: 7bit
|
||
X-Priority: 3 (Normal)
|
||
X-MSMail-Priority: Normal
|
||
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
|
||
X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400
|
||
Importance: Normal
|
||
In-Reply-To: <m13GofQ-000AX1C@druid.net>
|
||
X-Mailing-List: pgsql-hackers@postgresql.org
|
||
Precedence: bulk
|
||
Sender: pgsql-hackers-owner@hub.org
|
||
Status: OR
|
||
|
||
What RFC says you can't print all 4 octets of a CIDR Netnumber?
|
||
|
||
Why does network(cidr) return the whole cidr output just like
|
||
select cidr?
|
||
|
||
I'm just trying to figure out the logic here.
|
||
|
||
Here is what my Cisco Router that speaks BGP says:
|
||
big-bro#term ip netmask-format bit-count
|
||
big-bro#sh ip bg 206.66.0.0/20
|
||
BGP routing table entry for 206.66.0.0/20, version 150832
|
||
Paths: (5 available, best #4)
|
||
Advertised to non peer-group peers:
|
||
157.130.140.109 166.63.135.33 206.66.12.3 206.66.12.4 206.66.12.7
|
||
206.66.12.
|
||
8
|
||
Local, (aggregated by 4278 206.66.12.3), (received & used)
|
||
206.66.12.3 from 206.66.12.3 (206.66.12.3)
|
||
Origin IGP, localpref 0, valid, internal, atomic-aggregate
|
||
Local, (aggregated by 4278 206.66.12.7), (received & used)
|
||
206.66.12.7 from 206.66.12.7 (206.66.12.7)
|
||
Origin IGP, localpref 0, valid, internal, atomic-aggregate
|
||
Local, (aggregated by 4278 206.66.12.8), (received & used)
|
||
206.66.12.8 from 206.66.12.8 (206.66.12.8)
|
||
Origin IGP, localpref 0, valid, internal, atomic-aggregate
|
||
Local, (aggregated by 4278 206.66.12.1)
|
||
0.0.0.0 from 0.0.0.0 (206.66.12.1)
|
||
Origin IGP, localpref 100, weight 32768, valid, aggregated, local,
|
||
atomic-
|
||
aggregate, best
|
||
Local, (received & used)
|
||
206.66.12.4 from 206.66.12.4 (206.66.12.4)
|
||
Origin IGP, metric 0, localpref 100, valid, internal
|
||
big-bro#
|
||
|
||
I am just asking for the same type output.
|
||
|
||
Why is this so hard?
|
||
|
||
The info is in the type, and the print routine wouldn't be so hard.
|
||
|
||
I can probably write the function in less than 1 hour, but getting it
|
||
integrated is
|
||
my stumbling block.
|
||
|
||
|
||
|
||
-----Original Message-----
|
||
From: D'Arcy J.M. Cain [mailto:darcy@druid.net]
|
||
Sent: Monday, July 24, 2000 3:18 PM
|
||
To: Larry Rosenman
|
||
Cc: Don Baccus; pgsql-hackers@hub.org
|
||
Subject: Re: [HACKERS] INET/CIDR types
|
||
|
||
|
||
Thus spake Larry Rosenman
|
||
> I was hoping to have some niceties out of the SQL retrieve to print
|
||
directly
|
||
> in PHP, and not have to massage it.
|
||
>
|
||
> Why is there such animosity to printing out all 4 octets in some function
|
||
> somewhere for a CIDR block?
|
||
|
||
You keep saying "hostility" as if we are ganging up against you. Believe
|
||
me, I have no animosity towards you and I am sure no one else has either.
|
||
We are resisting the change you want simply because it would violate the
|
||
RFC which we agreed to follow when we created the types.
|
||
|
||
If you think this is hostile, you will probably think that the original
|
||
discussions in the archives are nuclear war :-). If you would like to
|
||
look it over make sure to set aside a lot of time. We spent a long time
|
||
hashing this out.
|
||
|
||
--
|
||
D'Arcy J.M. Cain <darcy@{druid|vex}.net> | Democracy is three wolves
|
||
http://www.druid.net/darcy/ | and a sheep voting on
|
||
+1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner.
|
||
|
||
|
||
From pgsql-hackers-owner+M5276@hub.org Mon Jul 24 16:54:14 2000
|
||
Received: from hub.org (root@hub.org [216.126.84.1])
|
||
by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id QAA11929
|
||
for <pgman@candle.pha.pa.us>; Mon, 24 Jul 2000 16:54:13 -0400 (EDT)
|
||
Received: from hub.org (majordom@localhost [127.0.0.1])
|
||
by hub.org (8.10.1/8.10.1) with SMTP id e6OKruh24719;
|
||
Mon, 24 Jul 2000 16:53:56 -0400 (EDT)
|
||
Received: from druid.net (root@druid.net [216.126.72.98])
|
||
by hub.org (8.10.1/8.10.1) with ESMTP id e6OKrPh24294
|
||
for <pgsql-hackers@hub.org>; Mon, 24 Jul 2000 16:53:25 -0400 (EDT)
|
||
Received: from localhost (1495 bytes) by druid.net
|
||
via sendmail with P:stdio/R:bind_hosts/T:inet_zone_bind_smtp
|
||
(sender: <darcy>) (ident <darcy> using unix)
|
||
id <m13GpE4-000AX0C@druid.net>
|
||
for <pgsql-hackers@hub.org>; Mon, 24 Jul 2000 16:53:24 -0400 (EDT)
|
||
(Smail-3.2.0.109 1999-Oct-27 #3 built 2000-Jun-28)
|
||
Message-Id: <m13GpE4-000AX0C@druid.net>
|
||
From: darcy@druid.net (D'Arcy J.M. Cain)
|
||
Subject: Re: [HACKERS] INET/CIDR types
|
||
In-Reply-To: <NCBBKBDOOHHEJCJHLLPAAELHHIAA.ler@lerctr.org> "from Larry Rosenman
|
||
at Jul 24, 2000 03:27:24 pm"
|
||
To: Larry Rosenman <ler@lerctr.org>
|
||
Date: Mon, 24 Jul 2000 16:53:24 -0400 (EDT)
|
||
CC: pgsql-hackers@hub.org, Don Baccus <dhogaza@pacifier.com>
|
||
Reply-To: pgsql-hackers@hub.org
|
||
X-Mailer: ELM [version 2.4ME+ PL78 (25)]
|
||
MIME-Version: 1.0
|
||
Content-Transfer-Encoding: 7bit
|
||
Content-Type: text/plain; charset=US-ASCII
|
||
X-Mailing-List: pgsql-hackers@postgresql.org
|
||
Precedence: bulk
|
||
Sender: pgsql-hackers-owner@hub.org
|
||
Status: OR
|
||
|
||
Thus spake Larry Rosenman
|
||
> What RFC says you can't print all 4 octets of a CIDR Netnumber?
|
||
|
||
Can't recall. It was Paul Vixie who made the claim and since he was
|
||
probably the one who wrote it I tend to believe him.
|
||
|
||
In fact it may be that it suggested rather than required but someone
|
||
would have to dig out the RFC before we considered changing it I think.
|
||
|
||
> Why does network(cidr) return the whole cidr output just like
|
||
> select cidr?
|
||
|
||
Yah, it's redundant. "network(cidr)" is just a long way to say "cidr."
|
||
The only reason it is there is because of the way the code was written
|
||
for the two types. Not having it would have required a special test to
|
||
look for it and technically it is correct so we didn't bother.
|
||
|
||
--
|
||
D'Arcy J.M. Cain <darcy@{druid|vex}.net> | Democracy is three wolves
|
||
http://www.druid.net/darcy/ | and a sheep voting on
|
||
+1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner.
|
||
|
||
From pgsql-hackers-owner+M5277@hub.org Mon Jul 24 17:12:12 2000
|
||
Received: from hub.org (root@hub.org [216.126.84.1])
|
||
by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id RAA12251
|
||
for <pgman@candle.pha.pa.us>; Mon, 24 Jul 2000 17:12:11 -0400 (EDT)
|
||
Received: from hub.org (majordom@localhost [127.0.0.1])
|
||
by hub.org (8.10.1/8.10.1) with SMTP id e6OLBth32813;
|
||
Mon, 24 Jul 2000 17:11:55 -0400 (EDT)
|
||
Received: from lerami.lerctr.org (lerami.lerctr.org [207.158.72.11])
|
||
by hub.org (8.10.1/8.10.1) with ESMTP id e6OLBah32716
|
||
for <pgsql-hackers@hub.org>; Mon, 24 Jul 2000 17:11:36 -0400 (EDT)
|
||
Received: from lerdesk (ler-desk.iadfw.net [206.66.13.18])
|
||
by lerami.lerctr.org (8.10.1/8.10.1/20000715) with SMTP id e6OLBZc28924;
|
||
Mon, 24 Jul 2000 16:11:35 -0500 (CDT)
|
||
From: "Larry Rosenman" <ler@lerctr.org>
|
||
To: <pgsql-hackers@hub.org>, "Larry Rosenman" <ler@lerctr.org>
|
||
Cc: "Don Baccus" <dhogaza@pacifier.com>
|
||
Subject: RE: [HACKERS] INET/CIDR types
|
||
Date: Mon, 24 Jul 2000 16:11:34 -0500
|
||
Message-ID: <NCBBKBDOOHHEJCJHLLPAIELMHIAA.ler@lerctr.org>
|
||
MIME-Version: 1.0
|
||
Content-Type: text/plain;
|
||
charset="iso-8859-1"
|
||
Content-Transfer-Encoding: 7bit
|
||
X-Priority: 3 (Normal)
|
||
X-MSMail-Priority: Normal
|
||
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
|
||
X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400
|
||
Importance: Normal
|
||
In-Reply-To: <m13GpE4-000AX0C@druid.net>
|
||
X-Mailing-List: pgsql-hackers@postgresql.org
|
||
Precedence: bulk
|
||
Sender: pgsql-hackers-owner@hub.org
|
||
Status: OR
|
||
|
||
Can we dig up the RFC?
|
||
|
||
Larry
|
||
|
||
-----Original Message-----
|
||
From: pgsql-hackers-owner@hub.org [mailto:pgsql-hackers-owner@hub.org]On
|
||
Behalf Of D'Arcy J.M. Cain
|
||
Sent: Monday, July 24, 2000 3:53 PM
|
||
To: Larry Rosenman
|
||
Cc: pgsql-hackers@hub.org; Don Baccus
|
||
Subject: Re: [HACKERS] INET/CIDR types
|
||
|
||
|
||
Thus spake Larry Rosenman
|
||
> What RFC says you can't print all 4 octets of a CIDR Netnumber?
|
||
|
||
Can't recall. It was Paul Vixie who made the claim and since he was
|
||
probably the one who wrote it I tend to believe him.
|
||
|
||
In fact it may be that it suggested rather than required but someone
|
||
would have to dig out the RFC before we considered changing it I think.
|
||
|
||
> Why does network(cidr) return the whole cidr output just like
|
||
> select cidr?
|
||
|
||
Yah, it's redundant. "network(cidr)" is just a long way to say "cidr."
|
||
The only reason it is there is because of the way the code was written
|
||
for the two types. Not having it would have required a special test to
|
||
look for it and technically it is correct so we didn't bother.
|
||
|
||
--
|
||
D'Arcy J.M. Cain <darcy@{druid|vex}.net> | Democracy is three wolves
|
||
http://www.druid.net/darcy/ | and a sheep voting on
|
||
+1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner.
|
||
|
||
From pgsql-hackers-owner+M5278@hub.org Mon Jul 24 18:31:03 2000
|
||
Received: from hub.org (root@hub.org [216.126.84.1])
|
||
by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id SAA12804
|
||
for <pgman@candle.pha.pa.us>; Mon, 24 Jul 2000 18:31:03 -0400 (EDT)
|
||
Received: from hub.org (majordom@localhost [127.0.0.1])
|
||
by hub.org (8.10.1/8.10.1) with SMTP id e6OMUmh59689;
|
||
Mon, 24 Jul 2000 18:30:48 -0400 (EDT)
|
||
Received: from anubis (anubis.ip23.net [212.83.32.60])
|
||
by hub.org (8.10.1/8.10.1) with ESMTP id e6OMTxh58656
|
||
for <pgsql-hackers@hub.org>; Mon, 24 Jul 2000 18:29:59 -0400 (EDT)
|
||
Received: from ip23.net (umbriel [212.83.32.61]) by anubis (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id AAA96097; Tue, 25 Jul 2000 00:29:42 +0200 (CEST)
|
||
Message-ID: <397CC356.7C78A018@ip23.net>
|
||
Date: Tue, 25 Jul 2000 00:29:42 +0200
|
||
From: Sevo Stille <sevo@ip23.net>
|
||
Reply-To: sevo@ip23.net
|
||
Organization: IP23
|
||
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
|
||
X-Accept-Language: en-GB,en,de,en-US
|
||
MIME-Version: 1.0
|
||
To: Larry Rosenman <ler@lerctr.org>
|
||
CC: pgsql-hackers@hub.org
|
||
Subject: Re: [HACKERS] INET/CIDR types
|
||
References: <NCBBKBDOOHHEJCJHLLPAMELAHIAA.ler@lerctr.org>
|
||
Content-Type: text/plain; charset=us-ascii
|
||
Content-Transfer-Encoding: 7bit
|
||
X-Mailing-List: pgsql-hackers@postgresql.org
|
||
Precedence: bulk
|
||
Sender: pgsql-hackers-owner@hub.org
|
||
Status: OR
|
||
|
||
Larry Rosenman wrote:
|
||
>
|
||
> The problem is NON-TECHNICAL people will be getting the output,
|
||
> and they expect 4 octet output.
|
||
|
||
Well, but what are they going to do if they see, say, that 196.100.0.0
|
||
is already allocated? Any CIDR net starting off on the .0 will have
|
||
exactly the same 4 octet notation. That is, the above entry would only
|
||
tell that there is some indeterminable number of addresses starting off
|
||
196.100.0.0 allocated, which could be anything between a measly /31 and
|
||
a whopping big /16. To repeat: CIDR having no implicit netmask encoded
|
||
in the class, there is no way of figuring out your allocation if you
|
||
lose the explicit mask. Which presumably will cause considerable
|
||
problems in a network allocation and tracking application!
|
||
|
||
> I really think that we should have a way to coerce a CIDR to
|
||
> an INET, and then allow host().
|
||
|
||
There is no unique mapping of a CIDR network to a INET host address,
|
||
except for the special case of /32.
|
||
|
||
> Remember that I am dealing with $10/hour clerks.
|
||
|
||
Then given them a interface which makes the concept of CIDR obvious to
|
||
them. Faking a classed notation is no way to go! IP v.4 being what it
|
||
is, and registries being on the move to enforce CIDR more and more, they
|
||
will inevitably encounter CIDR sooner or later, probably in a business
|
||
critical way.
|
||
|
||
> I really don't get the hostility to changing the OUTPUT format...
|
||
|
||
Anything broken that is added will sooner or later be used by somebody.
|
||
Which means that it can't be fixed without breaking some applications.
|
||
That alone should be a good enough reason not to introduce any broken
|
||
notions intentionally.
|
||
|
||
Sevo
|
||
|
||
--
|
||
Sevo Stille
|
||
sevo@ip23.net
|
||
|
||
From pgsql-hackers-owner+M5279@hub.org Mon Jul 24 18:31:24 2000
|
||
Received: from hub.org (root@hub.org [216.126.84.1])
|
||
by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id SAA12809
|
||
for <pgman@candle.pha.pa.us>; Mon, 24 Jul 2000 18:31:23 -0400 (EDT)
|
||
Received: from hub.org (majordom@localhost [127.0.0.1])
|
||
by hub.org (8.10.1/8.10.1) with SMTP id e6OMVBh60018;
|
||
Mon, 24 Jul 2000 18:31:11 -0400 (EDT)
|
||
Received: from paprika.michvhf.com (paprika.michvhf.com [209.103.136.12])
|
||
by hub.org (8.10.1/8.10.1) with SMTP id e6OMUrh59759
|
||
for <pgsql-hackers@hub.org>; Mon, 24 Jul 2000 18:30:53 -0400 (EDT)
|
||
Received: (qmail 39846 invoked by uid 1001); 24 Jul 2000 22:30:59 -0000
|
||
Date: Mon, 24 Jul 2000 18:30:59 -0400 (EDT)
|
||
From: Vince Vielhaber <vev@michvhf.com>
|
||
To: Larry Rosenman <ler@lerctr.org>
|
||
cc: pgsql-hackers@hub.org
|
||
Subject: RE: [HACKERS] INET/CIDR types
|
||
In-Reply-To: <NCBBKBDOOHHEJCJHLLPAIELMHIAA.ler@lerctr.org>
|
||
Message-ID: <Pine.BSF.4.21.0007241828230.36999-100000@paprika.michvhf.com>
|
||
MIME-Version: 1.0
|
||
Content-Type: TEXT/PLAIN; charset=US-ASCII
|
||
X-Mailing-List: pgsql-hackers@postgresql.org
|
||
Precedence: bulk
|
||
Sender: pgsql-hackers-owner@hub.org
|
||
Status: OR
|
||
|
||
On Mon, 24 Jul 2000, Larry Rosenman wrote:
|
||
|
||
> Can we dig up the RFC?
|
||
|
||
Feel free. You can start your research with RFC1467 and look back at
|
||
what it touches on, then on to 1517, 1518 and 1519 then to 1817 and
|
||
then to 2317. If, after reading these, you don't understand why and/or
|
||
why not you can check with Paul himself at www.vix.com, 'cuze if you
|
||
don't understand then he's your only hope.
|
||
|
||
Vince.
|
||
--
|
||
==========================================================================
|
||
Vince Vielhaber -- KA8CSH email: vev@michvhf.com http://www.pop4.net
|
||
128K ISDN from $22.00/mo - 56K Dialup from $16.00/mo at Pop4 Networking
|
||
Online Campground Directory http://www.camping-usa.com
|
||
Online Giftshop Superstore http://www.cloudninegifts.com
|
||
==========================================================================
|
||
|
||
|
||
|
||
|
||
From pgsql-hackers-owner+M5280@hub.org Mon Jul 24 18:53:56 2000
|
||
Received: from hub.org (root@hub.org [216.126.84.1])
|
||
by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id SAA12905
|
||
for <pgman@candle.pha.pa.us>; Mon, 24 Jul 2000 18:53:55 -0400 (EDT)
|
||
Received: from hub.org (majordom@localhost [127.0.0.1])
|
||
by hub.org (8.10.1/8.10.1) with SMTP id e6OMrjh74011;
|
||
Mon, 24 Jul 2000 18:53:45 -0400 (EDT)
|
||
Received: from anubis (anubis.ip23.net [212.83.32.60])
|
||
by hub.org (8.10.1/8.10.1) with ESMTP id e6OMrNh73763
|
||
for <pgsql-hackers@hub.org>; Mon, 24 Jul 2000 18:53:24 -0400 (EDT)
|
||
Received: from ip23.net (umbriel [212.83.32.61]) by anubis (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id AAA95973; Tue, 25 Jul 2000 00:52:30 +0200 (CEST)
|
||
Message-ID: <397CC8AE.FC342360@ip23.net>
|
||
Date: Tue, 25 Jul 2000 00:52:30 +0200
|
||
From: Sevo Stille <sevo@ip23.net>
|
||
Reply-To: sevo@ip23.net
|
||
Organization: IP23
|
||
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
|
||
X-Accept-Language: en-GB,en,de,en-US
|
||
MIME-Version: 1.0
|
||
To: Larry Rosenman <ler@lerctr.org>
|
||
CC: pgsql-hackers@hub.org, Don Baccus <dhogaza@pacifier.com>
|
||
Subject: Re: [HACKERS] INET/CIDR types
|
||
References: <NCBBKBDOOHHEJCJHLLPAAELHHIAA.ler@lerctr.org>
|
||
Content-Type: text/plain; charset=us-ascii
|
||
Content-Transfer-Encoding: 7bit
|
||
X-Mailing-List: pgsql-hackers@postgresql.org
|
||
Precedence: bulk
|
||
Sender: pgsql-hackers-owner@hub.org
|
||
Status: OR
|
||
|
||
Larry Rosenman wrote:
|
||
>
|
||
> What RFC says you can't print all 4 octets of a CIDR Netnumber?
|
||
|
||
Implicitly in 1518, for example:
|
||
---------8<----------------------8<----------------------8<------------
|
||
For the purposes of this paper, an IP prefix is an IP address and
|
||
some indication of the leftmost contiguous significant bits within
|
||
this address.
|
||
---------8<----------------------8<----------------------8<------------
|
||
|
||
As I already explained, the use of variable-length masks implies that
|
||
they have to be explicitly stated. This was not neccessary in classed
|
||
networks, as the MSB's encoded the class (mask).
|
||
|
||
> Why does network(cidr) return the whole cidr output just like
|
||
> select cidr?
|
||
|
||
Because a cast to network is a cast to CIDR - casting to the same type
|
||
obviously won't change a thing.
|
||
|
||
> I'm just trying to figure out the logic here.
|
||
|
||
As a matter of fact, it is the side effect of the current
|
||
implementations shortcomings - we have common code for INET and CIDR,
|
||
otherwise, network would not have to be a valid operator for CIDR.
|
||
|
||
> Here is what my Cisco Router that speaks BGP says:
|
||
> big-bro#term ip netmask-format bit-count
|
||
> big-bro#sh ip bg 206.66.0.0/20
|
||
> BGP routing table entry for 206.66.0.0/20, version 150832
|
||
> Paths: (5 available, best #4)
|
||
> Advertised to non peer-group peers:
|
||
> 157.130.140.109 166.63.135.33 206.66.12.3 206.66.12.4 206.66.12.7
|
||
> 206.66.12.
|
||
> ...
|
||
> I am just asking for the same type output.
|
||
|
||
Huh? The only *network* I see in there IS in /bits notation.
|
||
|
||
Sevo
|
||
|
||
--
|
||
Sevo Stille
|
||
sevo@ip23.net
|
||
|
||
From pgsql-hackers-owner+M5282@hub.org Mon Jul 24 19:05:38 2000
|
||
Received: from hub.org (root@hub.org [216.126.84.1])
|
||
by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id TAA13152
|
||
for <pgman@candle.pha.pa.us>; Mon, 24 Jul 2000 19:05:37 -0400 (EDT)
|
||
Received: from hub.org (majordom@localhost [127.0.0.1])
|
||
by hub.org (8.10.1/8.10.1) with SMTP id e6ON5Mh82281;
|
||
Mon, 24 Jul 2000 19:05:22 -0400 (EDT)
|
||
Received: from smtp.pacifier.com (comet.pacifier.com [199.2.117.155])
|
||
by hub.org (8.10.1/8.10.1) with ESMTP id e6ON4qh81966
|
||
for <pgsql-hackers@hub.org>; Mon, 24 Jul 2000 19:04:52 -0400 (EDT)
|
||
Received: from desktop (dsl-dhogaza.pacifier.net [207.202.226.68])
|
||
by smtp.pacifier.com (8.9.3/8.9.3pop) with SMTP id QAA16750;
|
||
Mon, 24 Jul 2000 16:04:27 -0700 (PDT)
|
||
Message-Id: <3.0.1.32.20000724160016.01192100@mail.pacifier.com>
|
||
X-Sender: dhogaza@mail.pacifier.com
|
||
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
|
||
Date: Mon, 24 Jul 2000 16:00:16 -0700
|
||
To: Vince Vielhaber <vev@michvhf.com>, Larry Rosenman <ler@lerctr.org>
|
||
From: Don Baccus <dhogaza@pacifier.com>
|
||
Subject: RE: [HACKERS] INET/CIDR types
|
||
Cc: pgsql-hackers@hub.org
|
||
In-Reply-To: <Pine.BSF.4.21.0007241828230.36999-100000@paprika.michvhf.c
|
||
om>
|
||
References: <NCBBKBDOOHHEJCJHLLPAIELMHIAA.ler@lerctr.org>
|
||
Mime-Version: 1.0
|
||
Content-Type: text/plain; charset="us-ascii"
|
||
X-Mailing-List: pgsql-hackers@postgresql.org
|
||
Precedence: bulk
|
||
Sender: pgsql-hackers-owner@hub.org
|
||
Status: OR
|
||
|
||
At 06:30 PM 7/24/00 -0400, Vince Vielhaber wrote:
|
||
>On Mon, 24 Jul 2000, Larry Rosenman wrote:
|
||
>
|
||
>> Can we dig up the RFC?
|
||
>
|
||
>Feel free. You can start your research with RFC1467 and look back at
|
||
>what it touches on, then on to 1517, 1518 and 1519 then to 1817 and
|
||
>then to 2317. If, after reading these, you don't understand why and/or
|
||
>why not you can check with Paul himself at www.vix.com, 'cuze if you
|
||
>don't understand then he's your only hope.
|
||
|
||
I bet just hacking your PHP script to format it in the way you want
|
||
would involve a heck of a lot less effort ...
|
||
|
||
|
||
|
||
- Don Baccus, Portland OR <dhogaza@pacifier.com>
|
||
Nature photos, on-line guides, Pacific Northwest
|
||
Rare Bird Alert Service and other goodies at
|
||
http://donb.photo.net.
|
||
|
||
From pgsql-hackers-owner+M5281@hub.org Mon Jul 24 19:01:25 2000
|
||
Received: from hub.org (root@hub.org [216.126.84.1])
|
||
by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id TAA12969
|
||
for <pgman@candle.pha.pa.us>; Mon, 24 Jul 2000 19:01:25 -0400 (EDT)
|
||
Received: from hub.org (majordom@localhost [127.0.0.1])
|
||
by hub.org (8.10.1/8.10.1) with SMTP id e6ON1Dh79863;
|
||
Mon, 24 Jul 2000 19:01:13 -0400 (EDT)
|
||
Received: from lerami.lerctr.org (lerami.lerctr.org [207.158.72.11])
|
||
by hub.org (8.10.1/8.10.1) with ESMTP id e6ON0rh79630
|
||
for <pgsql-hackers@hub.org>; Mon, 24 Jul 2000 19:00:53 -0400 (EDT)
|
||
Received: (from ler@localhost)
|
||
by lerami.lerctr.org (8.10.1/8.10.1/20000715) id e6ON0lO03554;
|
||
Mon, 24 Jul 2000 18:00:47 -0500 (CDT)
|
||
From: Larry Rosenman <ler@lerctr.org>
|
||
Message-Id: <200007242300.e6ON0lO03554@lerami.lerctr.org>
|
||
Subject: Re: [HACKERS] INET/CIDR types
|
||
In-Reply-To: <397CC8AE.FC342360@ip23.net> "from Sevo Stille at Jul 25, 2000 00:52:30
|
||
am"
|
||
To: sevo@ip23.net
|
||
Date: Mon, 24 Jul 2000 18:00:46 -0500 (CDT)
|
||
CC: Larry Rosenman <ler@lerctr.org>, pgsql-hackers@hub.org,
|
||
Don Baccus <dhogaza@pacifier.com>
|
||
X-Mailer: ELM [version 2.4ME+ PL79 (25)]
|
||
MIME-Version: 1.0
|
||
Content-Transfer-Encoding: 7bit
|
||
Content-Type: text/plain; charset=US-ASCII
|
||
X-Mailing-List: pgsql-hackers@postgresql.org
|
||
Precedence: bulk
|
||
Sender: pgsql-hackers-owner@hub.org
|
||
Status: OR
|
||
|
||
> Larry Rosenman wrote:
|
||
> >
|
||
> > What RFC says you can't print all 4 octets of a CIDR Netnumber?
|
||
>
|
||
> Implicitly in 1518, for example:
|
||
> ---------8<----------------------8<----------------------8<------------
|
||
> For the purposes of this paper, an IP prefix is an IP address and
|
||
> some indication of the leftmost contiguous significant bits within
|
||
> this address.
|
||
> ---------8<----------------------8<----------------------8<------------
|
||
This doesn't prohibit listing all 4 octets, which is my argument...
|
||
>
|
||
> As I already explained, the use of variable-length masks implies that
|
||
> they have to be explicitly stated. This was not neccessary in classed
|
||
> networks, as the MSB's encoded the class (mask).
|
||
I know this...
|
||
>
|
||
> > Why does network(cidr) return the whole cidr output just like
|
||
> > select cidr?
|
||
>
|
||
> Because a cast to network is a cast to CIDR - casting to the same type
|
||
> obviously won't change a thing.
|
||
>
|
||
> > I'm just trying to figure out the logic here.
|
||
>
|
||
> As a matter of fact, it is the side effect of the current
|
||
> implementations shortcomings - we have common code for INET and CIDR,
|
||
> otherwise, network would not have to be a valid operator for CIDR.
|
||
|
||
I just want something equivalent to host(inet) that
|
||
prints all 4 octets of a CIDR type with no mask.
|
||
|
||
Is that hard?
|
||
>
|
||
> > Here is what my Cisco Router that speaks BGP says:
|
||
> > big-bro#term ip netmask-format bit-count
|
||
> > big-bro#sh ip bg 206.66.0.0/20
|
||
> > BGP routing table entry for 206.66.0.0/20, version 150832
|
||
> > Paths: (5 available, best #4)
|
||
> > Advertised to non peer-group peers:
|
||
> > 157.130.140.109 166.63.135.33 206.66.12.3 206.66.12.4 206.66.12.7
|
||
> > 206.66.12.
|
||
> > ...
|
||
> > I am just asking for the same type output.
|
||
>
|
||
> Huh? The only *network* I see in there IS in /bits notation.
|
||
Yes, but with all 4 octets, which is all I'm looking for....
|
||
|
||
|
||
>
|
||
> Sevo
|
||
>
|
||
> --
|
||
> Sevo Stille
|
||
> sevo@ip23.net
|
||
|
||
|
||
--
|
||
Larry Rosenman http://www.lerctr.org/~ler
|
||
Phone: +1 972-414-9812 (voice) Internet: ler@lerctr.org
|
||
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
|
||
|
||
From pgsql-hackers-owner+M5285@hub.org Mon Jul 24 22:17:47 2000
|
||
Received: from hub.org (root@hub.org [216.126.84.1])
|
||
by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id WAA22852
|
||
for <pgman@candle.pha.pa.us>; Mon, 24 Jul 2000 22:17:46 -0400 (EDT)
|
||
Received: from hub.org (majordom@localhost [127.0.0.1])
|
||
by hub.org (8.10.1/8.10.1) with SMTP id e6P2CVh51074;
|
||
Mon, 24 Jul 2000 22:12:31 -0400 (EDT)
|
||
Received: from spider.pilosoft.com (p55-222.acedsl.com [160.79.55.222])
|
||
by hub.org (8.10.1/8.10.1) with ESMTP id e6P2Boh50884
|
||
for <pgsql-hackers@hub.org>; Mon, 24 Jul 2000 22:11:50 -0400 (EDT)
|
||
Received: from localhost (alexmail@localhost)
|
||
by spider.pilosoft.com (8.9.3/8.9.3) with ESMTP id WAA03783;
|
||
Mon, 24 Jul 2000 22:13:58 -0400 (EDT)
|
||
Date: Mon, 24 Jul 2000 22:13:57 -0400 (EDT)
|
||
From: Alex Pilosov <alex@pilosoft.com>
|
||
To: Sevo Stille <sevo@ip23.net>
|
||
cc: Larry Rosenman <ler@lerctr.org>, pgsql-hackers@hub.org
|
||
Subject: Re: [HACKERS] INET/CIDR types
|
||
In-Reply-To: <397CC356.7C78A018@ip23.net>
|
||
Message-ID: <Pine.BSO.4.10.10007242208480.4362-100000@spider.pilosoft.com>
|
||
MIME-Version: 1.0
|
||
Content-Type: TEXT/PLAIN; charset=US-ASCII
|
||
X-Mailing-List: pgsql-hackers@postgresql.org
|
||
Precedence: bulk
|
||
Sender: pgsql-hackers-owner@hub.org
|
||
Status: OR
|
||
|
||
This whole discussion is quite silly guys.
|
||
|
||
It is quite reasonable to have ability to split CIDR net into two pieces:
|
||
the network and the bitshift. Second one is already possible, the first
|
||
one can be accomplished by having functions to convert a cidr/inet to int8
|
||
(not int4 because of sign thing), and back.
|
||
|
||
Its also very easy to implement ;)
|
||
|
||
This will actually come very useful for many applications. Something I'm
|
||
working on now (allocation of 'most appropriate' block) requires ability
|
||
to split a netblock into two, which could be most easily accomplished
|
||
using int8 math. (net::int8+2^(netmask(net)-1)).
|
||
|
||
Now, patch anyone? :)
|
||
-alex
|
||
On Tue, 25 Jul 2000, Sevo Stille wrote:
|
||
|
||
> Larry Rosenman wrote:
|
||
> >
|
||
> > The problem is NON-TECHNICAL people will be getting the output,
|
||
> > and they expect 4 octet output.
|
||
>
|
||
> Well, but what are they going to do if they see, say, that 196.100.0.0
|
||
> is already allocated? Any CIDR net starting off on the .0 will have
|
||
> exactly the same 4 octet notation. That is, the above entry would only
|
||
> tell that there is some indeterminable number of addresses starting off
|
||
> 196.100.0.0 allocated, which could be anything between a measly /31 and
|
||
> a whopping big /16. To repeat: CIDR having no implicit netmask encoded
|
||
> in the class, there is no way of figuring out your allocation if you
|
||
> lose the explicit mask. Which presumably will cause considerable
|
||
> problems in a network allocation and tracking application!
|
||
>
|
||
> > I really think that we should have a way to coerce a CIDR to
|
||
> > an INET, and then allow host().
|
||
>
|
||
> There is no unique mapping of a CIDR network to a INET host address,
|
||
> except for the special case of /32.
|
||
>
|
||
> > Remember that I am dealing with $10/hour clerks.
|
||
>
|
||
> Then given them a interface which makes the concept of CIDR obvious to
|
||
> them. Faking a classed notation is no way to go! IP v.4 being what it
|
||
> is, and registries being on the move to enforce CIDR more and more, they
|
||
> will inevitably encounter CIDR sooner or later, probably in a business
|
||
> critical way.
|
||
>
|
||
> > I really don't get the hostility to changing the OUTPUT format...
|
||
>
|
||
> Anything broken that is added will sooner or later be used by somebody.
|
||
> Which means that it can't be fixed without breaking some applications.
|
||
> That alone should be a good enough reason not to introduce any broken
|
||
> notions intentionally.
|
||
>
|
||
> Sevo
|
||
>
|
||
>
|
||
|
||
|
||
From pgsql-hackers-owner+M5287@hub.org Mon Jul 24 22:48:05 2000
|
||
Received: from hub.org (root@hub.org [216.126.84.1])
|
||
by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id WAA23082
|
||
for <pgman@candle.pha.pa.us>; Mon, 24 Jul 2000 22:48:04 -0400 (EDT)
|
||
Received: from hub.org (majordom@localhost [127.0.0.1])
|
||
by hub.org (8.10.1/8.10.1) with SMTP id e6P2hrh58014;
|
||
Mon, 24 Jul 2000 22:43:53 -0400 (EDT)
|
||
Received: from lerami.lerctr.org (lerami.lerctr.org [207.158.72.11])
|
||
by hub.org (8.10.1/8.10.1) with ESMTP id e6P2hbh57922
|
||
for <pgsql-hackers@hub.org>; Mon, 24 Jul 2000 22:43:37 -0400 (EDT)
|
||
Received: (from ler@localhost)
|
||
by lerami.lerctr.org (8.10.1/8.10.1/20000715) id e6P2eVl12604;
|
||
Mon, 24 Jul 2000 21:40:31 -0500 (CDT)
|
||
From: Larry Rosenman <ler@lerctr.org>
|
||
Message-Id: <200007250240.e6P2eVl12604@lerami.lerctr.org>
|
||
Subject: Re: [HACKERS] INET/CIDR types
|
||
In-Reply-To: <Pine.BSO.4.10.10007242208480.4362-100000@spider.pilosoft.com>
|
||
"from Alex Pilosov at Jul 24, 2000 10:13:57 pm"
|
||
To: Alex Pilosov <alex@pilosoft.com>
|
||
Date: Mon, 24 Jul 2000 21:40:31 -0500 (CDT)
|
||
CC: Sevo Stille <sevo@ip23.net>, Larry Rosenman <ler@lerctr.org>,
|
||
pgsql-hackers@hub.org
|
||
X-Mailer: ELM [version 2.4ME+ PL79 (25)]
|
||
MIME-Version: 1.0
|
||
Content-Transfer-Encoding: 7bit
|
||
Content-Type: text/plain; charset=US-ASCII
|
||
X-Mailing-List: pgsql-hackers@postgresql.org
|
||
Precedence: bulk
|
||
Sender: pgsql-hackers-owner@hub.org
|
||
Status: OR
|
||
|
||
> This whole discussion is quite silly guys.
|
||
>
|
||
> It is quite reasonable to have ability to split CIDR net into two pieces:
|
||
> the network and the bitshift. Second one is already possible, the first
|
||
> one can be accomplished by having functions to convert a cidr/inet to int8
|
||
> (not int4 because of sign thing), and back.
|
||
>
|
||
> Its also very easy to implement ;)
|
||
>
|
||
> This will actually come very useful for many applications. Something I'm
|
||
> working on now (allocation of 'most appropriate' block) requires ability
|
||
> to split a netblock into two, which could be most easily accomplished
|
||
> using int8 math. (net::int8+2^(netmask(net)-1)).
|
||
All I'm looking for is to be able to print all 4 octets of an IP address
|
||
out so that joe user can take the 4 numbers and type it into the
|
||
4 boxes on a Windows 98 box, and use them.
|
||
|
||
Is that really that abhorrent?
|
||
|
||
They also need the 4 octet netmask which I can get now.
|
||
|
||
All we are missing is a way to print ALL 4 NUMBERS ALL THE TIME
|
||
for the output. It's not asking for classful, and for sure
|
||
we use CIDR all over the place, but for the final output that my
|
||
users see, why can't I have the database just print all 4 octets?
|
||
|
||
Why is this discussion so hard?
|
||
|
||
Larry
|
||
>
|
||
> Now, patch anyone? :)
|
||
> -alex
|
||
> On Tue, 25 Jul 2000, Sevo Stille wrote:
|
||
>
|
||
> > Larry Rosenman wrote:
|
||
> > >
|
||
> > > The problem is NON-TECHNICAL people will be getting the output,
|
||
> > > and they expect 4 octet output.
|
||
> >
|
||
> > Well, but what are they going to do if they see, say, that 196.100.0.0
|
||
> > is already allocated? Any CIDR net starting off on the .0 will have
|
||
> > exactly the same 4 octet notation. That is, the above entry would only
|
||
> > tell that there is some indeterminable number of addresses starting off
|
||
> > 196.100.0.0 allocated, which could be anything between a measly /31 and
|
||
> > a whopping big /16. To repeat: CIDR having no implicit netmask encoded
|
||
> > in the class, there is no way of figuring out your allocation if you
|
||
> > lose the explicit mask. Which presumably will cause considerable
|
||
> > problems in a network allocation and tracking application!
|
||
> >
|
||
> > > I really think that we should have a way to coerce a CIDR to
|
||
> > > an INET, and then allow host().
|
||
> >
|
||
> > There is no unique mapping of a CIDR network to a INET host address,
|
||
> > except for the special case of /32.
|
||
> >
|
||
> > > Remember that I am dealing with $10/hour clerks.
|
||
> >
|
||
> > Then given them a interface which makes the concept of CIDR obvious to
|
||
> > them. Faking a classed notation is no way to go! IP v.4 being what it
|
||
> > is, and registries being on the move to enforce CIDR more and more, they
|
||
> > will inevitably encounter CIDR sooner or later, probably in a business
|
||
> > critical way.
|
||
> >
|
||
> > > I really don't get the hostility to changing the OUTPUT format...
|
||
> >
|
||
> > Anything broken that is added will sooner or later be used by somebody.
|
||
> > Which means that it can't be fixed without breaking some applications.
|
||
> > That alone should be a good enough reason not to introduce any broken
|
||
> > notions intentionally.
|
||
> >
|
||
> > Sevo
|
||
> >
|
||
> >
|
||
>
|
||
|
||
|
||
--
|
||
Larry Rosenman http://www.lerctr.org/~ler
|
||
Phone: +1 972-414-9812 (voice) Internet: ler@lerctr.org
|
||
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
|
||
|
||
From pgsql-hackers-owner+M5288@hub.org Mon Jul 24 22:51:31 2000
|
||
Received: from hub.org (root@hub.org [216.126.84.1])
|
||
by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id WAA23098
|
||
for <pgman@candle.pha.pa.us>; Mon, 24 Jul 2000 22:51:30 -0400 (EDT)
|
||
Received: from hub.org (majordom@localhost [127.0.0.1])
|
||
by hub.org (8.10.1/8.10.1) with SMTP id e6P2omh59374;
|
||
Mon, 24 Jul 2000 22:50:48 -0400 (EDT)
|
||
Received: from spider.pilosoft.com (p55-222.acedsl.com [160.79.55.222])
|
||
by hub.org (8.10.1/8.10.1) with ESMTP id e6P2oah59301
|
||
for <pgsql-hackers@hub.org>; Mon, 24 Jul 2000 22:50:36 -0400 (EDT)
|
||
Received: from localhost (alexmail@localhost)
|
||
by spider.pilosoft.com (8.9.3/8.9.3) with ESMTP id WAA03944;
|
||
Mon, 24 Jul 2000 22:53:20 -0400 (EDT)
|
||
Date: Mon, 24 Jul 2000 22:53:20 -0400 (EDT)
|
||
From: Alex Pilosov <alex@pilosoft.com>
|
||
To: Larry Rosenman <ler@lerctr.org>
|
||
cc: Sevo Stille <sevo@ip23.net>, pgsql-hackers@hub.org
|
||
Subject: Re: [HACKERS] INET/CIDR types
|
||
In-Reply-To: <200007250240.e6P2eVl12604@lerami.lerctr.org>
|
||
Message-ID: <Pine.BSO.4.10.10007242252290.4362-100000@spider.pilosoft.com>
|
||
MIME-Version: 1.0
|
||
Content-Type: TEXT/PLAIN; charset=US-ASCII
|
||
X-Mailing-List: pgsql-hackers@postgresql.org
|
||
Precedence: bulk
|
||
Sender: pgsql-hackers-owner@hub.org
|
||
Status: OR
|
||
|
||
On Mon, 24 Jul 2000, Larry Rosenman wrote:
|
||
|
||
> > This whole discussion is quite silly guys.
|
||
> >
|
||
> > It is quite reasonable to have ability to split CIDR net into two pieces:
|
||
> > the network and the bitshift. Second one is already possible, the first
|
||
> > one can be accomplished by having functions to convert a cidr/inet to int8
|
||
> > (not int4 because of sign thing), and back.
|
||
> >
|
||
> > Its also very easy to implement ;)
|
||
> >
|
||
> > This will actually come very useful for many applications. Something I'm
|
||
> > working on now (allocation of 'most appropriate' block) requires ability
|
||
> > to split a netblock into two, which could be most easily accomplished
|
||
> > using int8 math. (net::int8+2^(netmask(net)-1)).
|
||
> All I'm looking for is to be able to print all 4 octets of an IP address
|
||
> out so that joe user can take the 4 numbers and type it into the
|
||
> 4 boxes on a Windows 98 box, and use them.
|
||
>
|
||
> Is that really that abhorrent?
|
||
>
|
||
> They also need the 4 octet netmask which I can get now.
|
||
>
|
||
> All we are missing is a way to print ALL 4 NUMBERS ALL THE TIME
|
||
> for the output. It's not asking for classful, and for sure
|
||
> we use CIDR all over the place, but for the final output that my
|
||
> users see, why can't I have the database just print all 4 octets?
|
||
|
||
Larry,
|
||
With my suggestion, you can do it as follows:
|
||
|
||
net::int8::inet
|
||
|
||
(net being of cidr type)
|
||
-alex
|
||
|
||
|
||
From pgsql-hackers-owner+M5290@hub.org Mon Jul 24 23:10:44 2000
|
||
Received: from hub.org (root@hub.org [216.126.84.1])
|
||
by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id XAA23371
|
||
for <pgman@candle.pha.pa.us>; Mon, 24 Jul 2000 23:10:44 -0400 (EDT)
|
||
Received: from hub.org (majordom@localhost [127.0.0.1])
|
||
by hub.org (8.10.1/8.10.1) with SMTP id e6P3ATh64149;
|
||
Mon, 24 Jul 2000 23:10:29 -0400 (EDT)
|
||
Received: from lerami.lerctr.org (lerami.lerctr.org [207.158.72.11])
|
||
by hub.org (8.10.1/8.10.1) with ESMTP id e6P3AAh64000
|
||
for <pgsql-hackers@hub.org>; Mon, 24 Jul 2000 23:10:10 -0400 (EDT)
|
||
Received: (from ler@localhost)
|
||
by lerami.lerctr.org (8.10.1/8.10.1/20000715) id e6P3A1v13825;
|
||
Mon, 24 Jul 2000 22:10:01 -0500 (CDT)
|
||
From: Larry Rosenman <ler@lerctr.org>
|
||
Message-Id: <200007250310.e6P3A1v13825@lerami.lerctr.org>
|
||
Subject: Re: [HACKERS] INET/CIDR types
|
||
In-Reply-To: <Pine.BSO.4.10.10007242252290.4362-100000@spider.pilosoft.com>
|
||
"from Alex Pilosov at Jul 24, 2000 10:53:20 pm"
|
||
To: Alex Pilosov <alex@pilosoft.com>
|
||
Date: Mon, 24 Jul 2000 22:10:01 -0500 (CDT)
|
||
CC: Larry Rosenman <ler@lerctr.org>, Sevo Stille <sevo@ip23.net>,
|
||
pgsql-hackers@hub.org
|
||
X-Mailer: ELM [version 2.4ME+ PL79 (25)]
|
||
MIME-Version: 1.0
|
||
Content-Transfer-Encoding: 7bit
|
||
Content-Type: text/plain; charset=US-ASCII
|
||
X-Mailing-List: pgsql-hackers@postgresql.org
|
||
Precedence: bulk
|
||
Sender: pgsql-hackers-owner@hub.org
|
||
Status: OR
|
||
|
||
The bad news is it doesn't work now...
|
||
|
||
|
||
ler=# select host(netblock::int8::inet) from networks;
|
||
ERROR: Cannot cast type 'cidr' to 'int8'
|
||
ler=# \d networks
|
||
Table "networks"
|
||
Attribute | Type | Modifier
|
||
---------------+--------------+----------
|
||
netblock | cidr |
|
||
router | integer |
|
||
interface | varchar(64) |
|
||
dest_ip | inet |
|
||
net_name | varchar(64) |
|
||
owner | integer |
|
||
origin | varchar(256) |
|
||
assigned_date | date |
|
||
assigned_by | varchar(64) |
|
||
asn | smallint |
|
||
|
||
ler=#
|
||
|
||
> On Mon, 24 Jul 2000, Larry Rosenman wrote:
|
||
>
|
||
> > > This whole discussion is quite silly guys.
|
||
> > >
|
||
> > > It is quite reasonable to have ability to split CIDR net into two pieces:
|
||
> > > the network and the bitshift. Second one is already possible, the first
|
||
> > > one can be accomplished by having functions to convert a cidr/inet to int8
|
||
> > > (not int4 because of sign thing), and back.
|
||
> > >
|
||
> > > Its also very easy to implement ;)
|
||
> > >
|
||
> > > This will actually come very useful for many applications. Something I'm
|
||
> > > working on now (allocation of 'most appropriate' block) requires ability
|
||
> > > to split a netblock into two, which could be most easily accomplished
|
||
> > > using int8 math. (net::int8+2^(netmask(net)-1)).
|
||
> > All I'm looking for is to be able to print all 4 octets of an IP address
|
||
> > out so that joe user can take the 4 numbers and type it into the
|
||
> > 4 boxes on a Windows 98 box, and use them.
|
||
> >
|
||
> > Is that really that abhorrent?
|
||
> >
|
||
> > They also need the 4 octet netmask which I can get now.
|
||
> >
|
||
> > All we are missing is a way to print ALL 4 NUMBERS ALL THE TIME
|
||
> > for the output. It's not asking for classful, and for sure
|
||
> > we use CIDR all over the place, but for the final output that my
|
||
> > users see, why can't I have the database just print all 4 octets?
|
||
>
|
||
> Larry,
|
||
> With my suggestion, you can do it as follows:
|
||
>
|
||
> net::int8::inet
|
||
>
|
||
> (net being of cidr type)
|
||
> -alex
|
||
>
|
||
|
||
|
||
--
|
||
Larry Rosenman http://www.lerctr.org/~ler
|
||
Phone: +1 972-414-9812 (voice) Internet: ler@lerctr.org
|
||
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
|
||
|
||
From pgsql-hackers-owner+M5291@hub.org Mon Jul 24 23:24:11 2000
|
||
Received: from hub.org (root@hub.org [216.126.84.1])
|
||
by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id XAA23433
|
||
for <pgman@candle.pha.pa.us>; Mon, 24 Jul 2000 23:24:10 -0400 (EDT)
|
||
Received: from hub.org (majordom@localhost [127.0.0.1])
|
||
by hub.org (8.10.1/8.10.1) with SMTP id e6P3Nfh69885;
|
||
Mon, 24 Jul 2000 23:23:41 -0400 (EDT)
|
||
Received: from spider.pilosoft.com (p55-222.acedsl.com [160.79.55.222])
|
||
by hub.org (8.10.1/8.10.1) with ESMTP id e6P3Mvh69635
|
||
for <pgsql-hackers@hub.org>; Mon, 24 Jul 2000 23:22:57 -0400 (EDT)
|
||
Received: from localhost (alexmail@localhost)
|
||
by spider.pilosoft.com (8.9.3/8.9.3) with ESMTP id XAA27580;
|
||
Mon, 24 Jul 2000 23:25:41 -0400 (EDT)
|
||
Date: Mon, 24 Jul 2000 23:25:41 -0400 (EDT)
|
||
From: Alex Pilosov <alex@pilosoft.com>
|
||
To: Larry Rosenman <ler@lerctr.org>
|
||
cc: Sevo Stille <sevo@ip23.net>, pgsql-hackers@hub.org
|
||
Subject: Re: [HACKERS] INET/CIDR types
|
||
In-Reply-To: <200007250310.e6P3A1v13825@lerami.lerctr.org>
|
||
Message-ID: <Pine.BSO.4.10.10007242314200.4362-100000@spider.pilosoft.com>
|
||
MIME-Version: 1.0
|
||
Content-Type: TEXT/PLAIN; charset=US-ASCII
|
||
X-Mailing-List: pgsql-hackers@postgresql.org
|
||
Precedence: bulk
|
||
Sender: pgsql-hackers-owner@hub.org
|
||
Status: OR
|
||
|
||
Yes, I know.
|
||
I didn't say it existed, I proposed to create a simple conversion function
|
||
that would do that, which is why I asked for a patch.
|
||
|
||
I'd do it myself but it'll take some time. Should be really simple,
|
||
something to the effect of return a.s_addr (where a is struct in_addr),
|
||
however, I'm not sure what's POSIXly correct way to do that.
|
||
|
||
|
||
|
||
On Mon, 24 Jul 2000, Larry Rosenman wrote:
|
||
|
||
> The bad news is it doesn't work now...
|
||
>
|
||
>
|
||
> ler=# select host(netblock::int8::inet) from networks;
|
||
> ERROR: Cannot cast type 'cidr' to 'int8'
|
||
> ler=# \d networks
|
||
> Table "networks"
|
||
> Attribute | Type | Modifier
|
||
> ---------------+--------------+----------
|
||
> netblock | cidr |
|
||
> router | integer |
|
||
> interface | varchar(64) |
|
||
> dest_ip | inet |
|
||
> net_name | varchar(64) |
|
||
> owner | integer |
|
||
> origin | varchar(256) |
|
||
> assigned_date | date |
|
||
> assigned_by | varchar(64) |
|
||
> asn | smallint |
|
||
>
|
||
> ler=#
|
||
>
|
||
> > On Mon, 24 Jul 2000, Larry Rosenman wrote:
|
||
> >
|
||
> > > > This whole discussion is quite silly guys.
|
||
> > > >
|
||
> > > > It is quite reasonable to have ability to split CIDR net into two pieces:
|
||
> > > > the network and the bitshift. Second one is already possible, the first
|
||
> > > > one can be accomplished by having functions to convert a cidr/inet to int8
|
||
> > > > (not int4 because of sign thing), and back.
|
||
> > > >
|
||
> > > > Its also very easy to implement ;)
|
||
> > > >
|
||
> > > > This will actually come very useful for many applications. Something I'm
|
||
> > > > working on now (allocation of 'most appropriate' block) requires ability
|
||
> > > > to split a netblock into two, which could be most easily accomplished
|
||
> > > > using int8 math. (net::int8+2^(netmask(net)-1)).
|
||
> > > All I'm looking for is to be able to print all 4 octets of an IP address
|
||
> > > out so that joe user can take the 4 numbers and type it into the
|
||
> > > 4 boxes on a Windows 98 box, and use them.
|
||
> > >
|
||
> > > Is that really that abhorrent?
|
||
> > >
|
||
> > > They also need the 4 octet netmask which I can get now.
|
||
> > >
|
||
> > > All we are missing is a way to print ALL 4 NUMBERS ALL THE TIME
|
||
> > > for the output. It's not asking for classful, and for sure
|
||
> > > we use CIDR all over the place, but for the final output that my
|
||
> > > users see, why can't I have the database just print all 4 octets?
|
||
> >
|
||
> > Larry,
|
||
> > With my suggestion, you can do it as follows:
|
||
> >
|
||
> > net::int8::inet
|
||
> >
|
||
> > (net being of cidr type)
|
||
> > -alex
|
||
> >
|
||
>
|
||
>
|
||
>
|
||
|
||
|
||
From pgsql-hackers-owner+M5292@hub.org Tue Jul 25 01:27:56 2000
|
||
Received: from hub.org (root@hub.org [216.126.84.1])
|
||
by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id BAA25020
|
||
for <pgman@candle.pha.pa.us>; Tue, 25 Jul 2000 01:27:56 -0400 (EDT)
|
||
Received: from hub.org (majordom@localhost [127.0.0.1])
|
||
by hub.org (8.10.1/8.10.1) with SMTP id e6P5RWh12976;
|
||
Tue, 25 Jul 2000 01:27:32 -0400 (EDT)
|
||
Received: from smtp.pacifier.com (comet.pacifier.com [199.2.117.155])
|
||
by hub.org (8.10.1/8.10.1) with ESMTP id e6P5PHh12429
|
||
for <pgsql-hackers@hub.org>; Tue, 25 Jul 2000 01:25:17 -0400 (EDT)
|
||
Received: from desktop (dsl-dhogaza.pacifier.net [207.202.226.68])
|
||
by smtp.pacifier.com (8.9.3/8.9.3pop) with SMTP id WAA04370;
|
||
Mon, 24 Jul 2000 22:25:00 -0700 (PDT)
|
||
Message-Id: <3.0.1.32.20000724221204.01198400@mail.pacifier.com>
|
||
X-Sender: dhogaza@mail.pacifier.com
|
||
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
|
||
Date: Mon, 24 Jul 2000 22:12:04 -0700
|
||
To: Larry Rosenman <ler@lerctr.org>, Alex Pilosov <alex@pilosoft.com>
|
||
From: Don Baccus <dhogaza@pacifier.com>
|
||
Subject: Re: [HACKERS] INET/CIDR types
|
||
Cc: Sevo Stille <sevo@ip23.net>, Larry Rosenman <ler@lerctr.org>,
|
||
pgsql-hackers@hub.org
|
||
In-Reply-To: <200007250240.e6P2eVl12604@lerami.lerctr.org>
|
||
References: <Pine.BSO.4.10.10007242208480.4362-100000@spider.pilosoft.com>
|
||
Mime-Version: 1.0
|
||
Content-Type: text/plain; charset="us-ascii"
|
||
X-Mailing-List: pgsql-hackers@postgresql.org
|
||
Precedence: bulk
|
||
Sender: pgsql-hackers-owner@hub.org
|
||
Status: OR
|
||
|
||
At 09:40 PM 7/24/00 -0500, Larry Rosenman wrote:
|
||
|
||
>Why is this discussion so hard?
|
||
|
||
Because it's an output format you could easily solve yourself. Could've
|
||
solved yourself long ago.
|
||
|
||
If you care so much, change the sources and run your own custom version.
|
||
The beauty of open source, you get to break it in whatever manner you
|
||
choose.
|
||
|
||
Or hack your PHP script.
|
||
|
||
If you need help hacking your script you can probably get help, here. I'm
|
||
sure people are tired enough of this thread to write it for you, if that's
|
||
necessary.
|
||
|
||
Next I suppose you'll ask that Unix "ls" output switch "/" to
|
||
"\" so your $10 clerks can understand the output?
|
||
|
||
|
||
|
||
- Don Baccus, Portland OR <dhogaza@pacifier.com>
|
||
Nature photos, on-line guides, Pacific Northwest
|
||
Rare Bird Alert Service and other goodies at
|
||
http://donb.photo.net.
|
||
|
||
From pgsql-hackers-owner+M5321@hub.org Tue Jul 25 16:45:35 2000
|
||
Received: from hub.org (root@hub.org [216.126.84.1])
|
||
by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id QAA19032
|
||
for <pgman@candle.pha.pa.us>; Tue, 25 Jul 2000 16:45:34 -0400 (EDT)
|
||
Received: from hub.org (majordom@localhost [127.0.0.1])
|
||
by hub.org (8.10.1/8.10.1) with SMTP id e6PKieh98955;
|
||
Tue, 25 Jul 2000 16:44:40 -0400 (EDT)
|
||
Received: from merganser.its.uu.se (merganser.its.uu.se [130.238.6.236])
|
||
by hub.org (8.10.1/8.10.1) with ESMTP id e6PKenh96652
|
||
for <pgsql-hackers@hub.org>; Tue, 25 Jul 2000 16:40:49 -0400 (EDT)
|
||
Received: from regulus.student.UU.SE ([130.238.5.2]:40690 "EHLO
|
||
regulus.its.uu.se") by merganser.its.uu.se with ESMTP
|
||
id <S291004AbQGYUkH>; Tue, 25 Jul 2000 22:40:07 +0200
|
||
Received: from peter (helo=localhost)
|
||
by regulus.its.uu.se with local-esmtp (Exim 3.02 #2)
|
||
id 13HBVx-0001cn-00; Tue, 25 Jul 2000 22:41:21 +0200
|
||
Date: Tue, 25 Jul 2000 22:41:21 +0200 (CEST)
|
||
From: Peter Eisentraut <peter_e@gmx.net>
|
||
To: pgsql-hackers@hub.org
|
||
cc: Larry Rosenman <ler@lerctr.org>
|
||
Subject: Re: [HACKERS] INET/CIDR types
|
||
In-Reply-To: <m13Gngs-000AXeC@druid.net>
|
||
Message-ID: <Pine.LNX.4.21.0007251905480.546-100000@localhost.localdomain>
|
||
MIME-Version: 1.0
|
||
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
|
||
Content-Transfer-Encoding: 8BIT
|
||
X-Mailing-List: pgsql-hackers@postgresql.org
|
||
Precedence: bulk
|
||
Sender: pgsql-hackers-owner@hub.org
|
||
Status: OR
|
||
|
||
D'Arcy J.M. Cain writes:
|
||
|
||
> Hmmm. I just noticed this.
|
||
>
|
||
> darcy=> select '1.2.0.1/23'::cidr;
|
||
> ?column?
|
||
> --------
|
||
> 1.2.0/23
|
||
> (1 row)
|
||
>
|
||
> Shouldn't that throw an error?
|
||
|
||
Isn't that what I've been saying all along?
|
||
|
||
|
||
--
|
||
Peter Eisentraut Sernanders v<>g 10:115
|
||
peter_e@gmx.net 75262 Uppsala
|
||
http://yi.org/peter-e/ Sweden
|
||
|
||
|
||
From pgsql-hackers-owner+M5370@hub.org Thu Jul 27 06:17:36 2000
|
||
Received: from hub.org (root@hub.org [216.126.84.1])
|
||
by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id GAA24699
|
||
for <pgman@candle.pha.pa.us>; Thu, 27 Jul 2000 06:17:35 -0400 (EDT)
|
||
Received: from hub.org (majordom@localhost [127.0.0.1])
|
||
by hub.org (8.10.1/8.10.1) with SMTP id e6RAHRA44622;
|
||
Thu, 27 Jul 2000 06:17:27 -0400 (EDT)
|
||
Received: from druid.net (root@druid.net [216.126.72.98])
|
||
by hub.org (8.10.1/8.10.1) with ESMTP id e6RAH2A44416
|
||
for <pgsql-hackers@hub.org>; Thu, 27 Jul 2000 06:17:02 -0400 (EDT)
|
||
Received: from localhost (1387 bytes) by druid.net
|
||
via sendmail with P:stdio/R:bind_hosts/T:inet_zone_bind_smtp
|
||
(sender: <darcy>) (ident <darcy> using unix)
|
||
id <m13Hkik-000AX9C@druid.net>
|
||
for <pgsql-hackers@hub.org>; Thu, 27 Jul 2000 06:16:54 -0400 (EDT)
|
||
(Smail-3.2.0.109 1999-Oct-27 #3 built 2000-Jun-28)
|
||
Message-Id: <m13Hkik-000AX9C@druid.net>
|
||
From: darcy@druid.net (D'Arcy J.M. Cain)
|
||
Subject: Re: [HACKERS] INET/CIDR types
|
||
In-Reply-To: <Pine.LNX.4.21.0007251905480.546-100000@localhost.localdomain>
|
||
"from Peter Eisentraut at Jul 25, 2000 10:41:21 pm"
|
||
To: Peter Eisentraut <peter_e@gmx.net>
|
||
Date: Thu, 27 Jul 2000 06:16:54 -0400 (EDT)
|
||
CC: pgsql-hackers@hub.org, Larry Rosenman <ler@lerctr.org>
|
||
Reply-To: pgsql-hackers@hub.org
|
||
X-Mailer: ELM [version 2.4ME+ PL78 (25)]
|
||
MIME-Version: 1.0
|
||
Content-Transfer-Encoding: 7bit
|
||
Content-Type: text/plain; charset=US-ASCII
|
||
X-Mailing-List: pgsql-hackers@postgresql.org
|
||
Precedence: bulk
|
||
Sender: pgsql-hackers-owner@hub.org
|
||
Status: OR
|
||
|
||
Thus spake Peter Eisentraut
|
||
> > Hmmm. I just noticed this.
|
||
> >
|
||
> > darcy=> select '1.2.0.1/23'::cidr;
|
||
> > ?column?
|
||
> > --------
|
||
> > 1.2.0/23
|
||
> > (1 row)
|
||
> >
|
||
> > Shouldn't that throw an error?
|
||
>
|
||
> Isn't that what I've been saying all along?
|
||
|
||
Well, yes but I thought that it was now and that you were arguing to keep
|
||
that behaviour. This seems to be the behaviour that I was suggesting
|
||
although you have half convinced me that this should throw an error.
|
||
|
||
So, it looks like the status quo is for inet::cidr to be a different
|
||
spelling for network(inet). Is this the way we want to keep it?
|
||
|
||
--
|
||
D'Arcy J.M. Cain <darcy@{druid|vex}.net> | Democracy is three wolves
|
||
http://www.druid.net/darcy/ | and a sheep voting on
|
||
+1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner.
|
||
|