Thread: INET/CIDR types
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
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.
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
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.
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.
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 Serviceand other goodies at http://donb.photo.net.
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 Serviceand other goodies at http://donb.photo.net.
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.
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.4206.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.7from 206.66.12.7 (206.66.12.7) Origin IGP, localpref 0, valid, internal, atomic-aggregate Local,
(aggregatedby 4278 206.66.12.8), (received & used) 206.66.12.8 from 206.66.12.8 (206.66.12.8) Origin IGP,
localpref0, 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,
localpref100, 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.
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.
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.
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
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.net128K ISDN from $22.00/mo - 56K Dialup from $16.00/moat Pop4 Networking Online Campground Directory http://www.camping-usa.com Online Giftshop Superstore http://www.cloudninegifts.com ==========================================================================
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 significantbits 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
> 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
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 Serviceand other goodies at http://donb.photo.net.
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 > >
> 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
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
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
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 > > > > >
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 Serviceand other goodies at http://donb.photo.net.
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
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.
I have packaged up all the CIDR/INET discussion and put it in doc/TODO.detail/cidr. Also added to TODO: * Fix improper masking of some inet/cidr types [cidr] > 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 > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026