On Fri, 11 Jan 2008, Tom Lane wrote:
> Pomarede Nicolas <npomarede@corp.free.fr> writes:
>> As ip4r seems to work very well with postgresql, is there a possibility to
>> see it merged in postgresql, to have a native 4 bytes IPv4 address date
>> type ?
>
> Given that the world is going to IPv6 in a few years whether you like it
> or not, that seems pretty darn short-sighted to me.
>
> What would make sense IMHO is to adapt the improved indexing support in
> ip4r to work on the native inet/cidr types.
>
I understand your point on IPv6, but still being able to store IPv4
addresses with as little overhead as possible is important.
IPv6 will certainly grow in the year to come, but if you consider the case
of a very large private lan, with ip in the form 10.x.y.z, the fact that
the outside world is now ipv6 doesn't necessarily imply you will rename
all your internal equipments to be ipv6 if you don't need more addresses
(you can do the translation when packets cross the ipv6/ipv4 gateway in
your network).
To be more concret, I'm working for a large french ISP, so far we have 2+
millions "boxes" (triple play adsl equipments) at our customers' home.
All theses boxes have a private IPv4 address in 10.x.y.z as well as a
public IPV4 address, and although we recently activated a public IPv6 addr
on these boxes too (which certainly gives one of the biggest IPv6 network
so far), we still need to store one ipv4 and one ipv6 addr for each box.
So, my point was not to be short-sighted, we will go IPv6 for sure, it's
just that there're a lot of applications where storing ipv4 addr could be
needed (whether ipv6 is required for other applications or not), and in
this regard, I think that being able to store ipv4 addr with 4 bytes
instead of 8 could be appreciated.
Or perhaps another solution would be to have built-in inet_aton /
inet_ntoa functions in postgres, to store the result using an integer
(unsigned) ?
Nicolas