Re: [HACKERS] Linux.conf.au 2003 Report - Mailing list pgsql-advocacy

From Kurt Roeckx
Subject Re: [HACKERS] Linux.conf.au 2003 Report
Date
Msg-id 20030130195959.GA32255@ping.be
Whole thread Raw
In response to Re: [HACKERS] Linux.conf.au 2003 Report  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [HACKERS] Linux.conf.au 2003 Report
List pgsql-advocacy
On Thu, Jan 30, 2003 at 11:28:41AM -0500, Tom Lane wrote:
>
> > Also, what are the implications to functions such as network_sub,
> > network_cmp, etc. when given mixed v4/v6 inputs as could easily happen if the
> > two are freely mixed in the same data type?
>
> 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.

Some thing you also shouldn't forget for ipv6 addresses is the
scope.  An address with a scope of the link can be assigned to
several interfaces.  If they want to differentiate between them,
should they be able to store it the same field, or use a
different one?

My question really is how you're going to store it.  Are you
going to store is as a character string, or as binary?
If you store is as binary, how will you know if it's an ipv4 or
ipv6 address?  Based on the size?

From an application point of view it's more handy if you have a
combination of the address family and the data, so they don't
have to guess all the time.


P.S.: I don't really like the ipv6 patch.  It's more complicated
than it should be.  I really don't have the time to fix it/do it
better though.


Kurt


pgsql-advocacy by date:

Previous
From: Jason Hihn
Date:
Subject: Re: Oracle CEO on the limits of open-source databases.
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] Linux.conf.au 2003 Report