| 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: | Whole Thread | Raw Message | 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 |