well, now i wish we hadn't gutted the ipv6 support
my original CIDR type implementation used BIND's inet_ntop() and inet_pton()
which therefore included latent support for ipv6. it wouldn't take a huge
amount of effort to bring this back, would it?
(the user below is using VARCHAR for his ip addresses for this reason.)
------- Forwarded Message
Date: Fri, 20 Apr 2001 08:37:22 -0700 (PDT)
Message-Id: <200104201537.IAA26178@gulag.araneus.fi>
To: Paul A Vixie <vixie@mfnx.net>
Subject: Re: Appliance caching server configuration database schema
In-Reply-To: <200104200314.UAA73417@redpaul.mfnx.net>
From: gson@nominum.com (Andreas Gustafsson)
Paul A. Vixie writes:
you can use INET or CIDR for your addresses since this is postgres.
I would if it supported IPv6 addresses.
------- End of Forwarded Message
Paul A Vixie <vixie@mfnx.net> writes:
my original CIDR type implementation used BIND's inet_ntop() and inet_pton()
which therefore included latent support for ipv6. it wouldn't take a huge
amount of effort to bring this back, would it?
AFAIK we never actually *had* IPV6 support in those datatypes, only
stubs for it. A patch to bring it up to full speed would be gladly
accepted...
regards, tom lane
AFAIK we never actually *had* IPV6 support in those datatypes, only
stubs for it.
the inet_net_pton implementation that was brought in from BIND had its
IPv6 portions scrubbed. micro-over-optimization of the contributed
"bitncmp" caused the "ipv4 as int" assumption to reoccur. i'm going to
have to put it back to BIND-standard as much as possible. presumably
as long as the on-disk format is compatible (such that old databases can
be both read and written by the new code) none of that will be objectionable.
A patch to bring it up to full speed would be gladly accepted...
thanks for the invitation, i'll start work on it right now.