Thread: IP addresses
I am planning on doing a LOT of work with ip addresses and thought that the inet data type would be a great place to start.
But I'm not sure how this works in with accessing the addresses. In perl or ruby how is the value returned?
Or should I stricly use host() and other functions to be explicit about what I'm doing.
Another question.
Given a subnet (eg: 192.168.1.0/24) is there some way to pull all the addresses therein?
I can do this in code - but I was curious if there was a postgres way of doing it (didn't see any, but..)
2007/11/19, Tom Allison <tom@tacocat.net>: > I am planning on doing a LOT of work with ip addresses and thought that the > inet data type would be a great place to start. > > But I'm not sure how this works in with accessing the addresses. In perl or > ruby how is the value returned? In Perl the value is returned as a scalar. > Or should I stricly use host() and other functions to be explicit about what > I'm doing. > > > Another question. > Given a subnet (eg: 192.168.1.0/24) is there some way to pull all the > addresses therein? > I can do this in code - but I was curious if there was a postgres way of > doing it (didn't see any, but..) You want the network address functions and operators, I presume: http://www.postgresql.org/docs/8.2/interactive/functions-net.html HTH Ian Barwick -- http://sql-info.de/index.html
In article <aa6023de0711190526o40c7c32cs58279b196d4577ef@mail.gmail.com>, "Tom Allison" <tom@tacocat.net> writes: > I am planning on doing a LOT of work with ip addresses and thought that the > inet data type would be a great place to start. Forget inet. Check out http://pgfoundry.org/projects/ip4r/ and be happy.
Hi, ----- Original Message ----- From: "Harald Fuchs" <hf0217x@protecting.net> To: <pgsql-general@postgresql.org> Sent: Monday, November 19, 2007 7:21 PM Subject: Re: [GENERAL] IP addresses > In article <aa6023de0711190526o40c7c32cs58279b196d4577ef@mail.gmail.com>, > "Tom Allison" <tom@tacocat.net> writes: > >> I am planning on doing a LOT of work with ip addresses and thought that >> the >> inet data type would be a great place to start. > > Forget inet. Check out http://pgfoundry.org/projects/ip4r/ and be happy. I would be happy if it would support IPv6 :-) Are there plans to make ip6r or something like that? Thanks, Sander
"Sander Steffann" <s.steffann@computel.nl> writes: > From: "Harald Fuchs" <hf0217x@protecting.net> >> Forget inet. Check out http://pgfoundry.org/projects/ip4r/ and be happy. > I would be happy if it would support IPv6 :-) Are there plans to make ip6r > or something like that? What's the point? You might as well use the regular inet type if you need to handle ipv6. regards, tom lane
On Nov 20, 2007, at 3:41 PM, Tom Lane wrote: > "Sander Steffann" <s.steffann@computel.nl> writes: >> From: "Harald Fuchs" <hf0217x@protecting.net> >>> Forget inet. Check out http://pgfoundry.org/projects/ip4r/ and >>> be happy. > >> I would be happy if it would support IPv6 :-) Are there plans to >> make ip6r >> or something like that? > > What's the point? You might as well use the regular inet type if you > need to handle ipv6. ip4r's main advantage over inet is that it allows you to answer the question "is this IP address in any of these large number of address ranges" efficiently. It's useful for customer address allocation, email filtering blacklists, things like that. A range-indexable ipv6 type would be useful in theory, but I've not seen a need for it in production yet. When there is, extending ip4r to become ip6r would be possible. Cheers, Steve
Steve Atkins wrote:
>
> On Nov 20, 2007, at 3:41 PM, Tom Lane wrote:
>
>> "Sander Steffann" <s.steffann@computel.nl> writes:
>>> I would be happy if it would support IPv6 :-) Are there plans to make
>>> ip6r
>>> or something like that?
>>
>> What's the point? You might as well use the regular inet type if you
>> need to handle ipv6.
>
> ip4r's main advantage over inet is that it allows you to answer
> the question "is this IP address in any of these large number of
> address ranges" efficiently. It's useful for customer address
> allocation, email filtering blacklists, things like that.
Another advantage is that it's not varlena (this is less of a problem in
8.3 due to short varlenas, but having a fixed-length field is still
better).
--
Alvaro Herrera Valdivia, Chile ICBM: S 39º 49' 18.1", W 73º 13' 56.4"
"I must say, I am absolutely impressed with what pgsql's implementation of
VALUES allows me to do. It's kind of ridiculous how much "work" goes away in
my code. Too bad I can't do this at work (Oracle 8/9)." (Tom Allison)
http://archives.postgresql.org/pgsql-general/2007-06/msg00016.php
Hi Tom, > "Sander Steffann" <s.steffann@computel.nl> writes: > > From: "Harald Fuchs" <hf0217x@protecting.net> > >> Forget inet. Check out http://pgfoundry.org/projects/ip4r/ and be > happy. > > > I would be happy if it would support IPv6 :-) Are there plans to > > make ip6r or something like that? > > What's the point? You might as well use the regular inet type if you > need to handle ipv6. Well, the OP said to forget about inet, and I like the ip4r range type. I hoped there was something better/nicer/shinier :-) Thanks, Sander