mirror of
https://git.postgresql.org/git/postgresql.git
synced 2024-09-07 00:59:27 +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.
|
|||
|
|