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

Re: [HACKERS] Linux.conf.au 2003 Report

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Kurt Roeckx <Q(at)ping(dot)be>
Cc: Steve Crawford <scrawford(at)pinpointresearch(dot)com>,Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au>,Hackers <pgsql-hackers(at)postgresql(dot)org>,Advocacy <pgsql-advocacy(at)postgresql(dot)org>
Subject: Re: [HACKERS] Linux.conf.au 2003 Report
Date: 2003-01-31 01:13:30
Message-ID: 4800.1043975610@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-advocacypgsql-hackers
Kurt Roeckx <Q(at)ping(dot)be> writes:
> On Thu, Jan 30, 2003 at 11:28:41AM -0500, Tom Lane wrote:
>> We have to work out what the semantics should be.  I don't know anything
>> about v6, but I'd imagine v4 addresses form a defined subset of the v6
>> address space ... if so the semantics seem pretty straightforward.

> You have a "ipv4 mapped ipv6 address".  The ipv4 address 1.2.3.4 becomes
> ::ffff:1.2.3.4.  But I'm not really in favour of automatically
> changing an ipv4 address to an ipv6 address.  And you really
> shouldn't return an ipv4 address as an ipv6 address.

No, we should keep the distinction for purposes of storage and display.
The question was about what the semantics should be when comparing v4
and v6 addresses in operations like network_sub.  It seems perfectly
reasonable to convert the v4 address to the mapped v6 equivalent and then
do a v6 comparison in that situation.  Do we have any operators where
this would not be a sensible definition?

> My question really is how you're going to store it.  Are you
> going to store is as a character string, or as binary?

Binary, same as we do now for v4.

> If you store is as binary, how will you know if it's an ipv4 or
> ipv6 address?  Based on the size?

Why not?

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: Jan WieckDate: 2003-01-31 01:52:50
Subject: Re: [mail] Re: Windows Build System
Previous:From: Tom LaneDate: 2003-01-31 00:05:48
Subject: Re: [PATCHES] v7.2.4 bundled ...

pgsql-advocacy by date

Next:From: Curt SampsonDate: 2003-01-31 01:57:17
Subject: Re: Linux.conf.au 2003 Report
Previous:From: Kurt RoeckxDate: 2003-01-30 19:59:59
Subject: Re: [HACKERS] Linux.conf.au 2003 Report

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