Skip site navigation (1) Skip section navigation (2)

Re: Linux.conf.au 2003 Report

From: Curt Sampson <cjs(at)cynic(dot)net>
To: Andrew Sullivan <andrew(at)libertyrms(dot)info>
Cc: Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Linux.conf.au 2003 Report
Date: 2003-01-31 01:57:17
Message-ID: Pine.NEB.4.51.0301311053240.5220@angelic.cynic.net (view raw or flat)
Thread:
Lists: pgsql-advocacypgsql-hackers
On Thu, 30 Jan 2003, Andrew Sullivan wrote:

> Given that IPv6 is supposed to allow co-operation with IPv4, it seems
> it'd be pretty hard to force such a view on every application using
> IP addresses.  DNS, for instance.

Hm? DNS completely separates IPv4 and IPv6 addresses; they're different
record types ("A" versus "AAAA") in the DNS "database".

And the "interoperation" if IPv4 and IPv6 is pretty much not happening,
if you're talking about the compatability addresses. I won't get into
all the reasons why.

All that said, I'm not advocating separating (or not separating)
IPv4 and IPv6 addresses. I'm still undecided on the issue. I can see
situations where I might want to store both together, but then again, I
can see situations where I certainly wouldn't.

Perhaps we should think about another example to try to illuminate this:
what about storing ISO/OSI addresses in the same type as well? Isn't
that just the same thing as storing IPv4 and IPv6 addresses together?

cjs
-- 
Curt Sampson  <cjs(at)cynic(dot)net>   +81 90 7737 2974   http://www.netbsd.org
    Don't you know, in this new Dark Age, we're all light.  --XTC

In response to

Responses

pgsql-hackers by date

Next:From: Curt SampsonDate: 2003-01-31 01:58:48
Subject: Re: [HACKERS] Linux.conf.au 2003 Report
Previous:From: Jan WieckDate: 2003-01-31 01:52:50
Subject: Re: [mail] Re: Windows Build System

pgsql-advocacy by date

Next:From: Curt SampsonDate: 2003-01-31 01:58:48
Subject: Re: [HACKERS] Linux.conf.au 2003 Report
Previous:From: Tom LaneDate: 2003-01-31 01:13:30
Subject: Re: [HACKERS] Linux.conf.au 2003 Report

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group