Re: IPv6 link-local addresses and init data type

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Tom Dunstan <pgsql(at)tomd(dot)cc>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: IPv6 link-local addresses and init data type
Date: 2016-05-30 16:37:49
Message-ID: 12688.1464626269@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Dunstan <pgsql(at)tomd(dot)cc> writes:
> Basically the inet data type cannot store or parse valid ipv6 address literals with a scope / zone id suffix. Apparently the combination of virtualised linux, ipv6 network and JVM that we are using has combined to report connections on localhost as coming from ::1%0, which our app is unsuccessfully attempting to store in the db in an inet column. This is the first time that I have ever seen this, but perhaps it will get more common as ipv6-first usage increases.

> Given that inet is a varlena struct with only known-length fields, it seems potentially possible to extend it to add an optional, variable length zone id on the end, with the result being backwards compatible with existing data.

> Thoughts?

The impression I have is that scopes are not very well standardized ---
eg, OS X reports things like "fe80::1%lo0" not just "%0". If we could
get around that problem it would be worth doing.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Vladimir Borodin 2016-05-30 17:03:13 Re: 9.4 -> 9.5 regression with queries through pgbouncer on RHEL 6
Previous Message Tom Lane 2016-05-30 16:30:23 Re: "Allow usage of huge maintenance_work_mem for GIN build" patch