Обсуждение: 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.