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
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 |