From: | Tom Dunstan <pgsql(at)tomd(dot)cc> |
---|---|
To: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | IPv6 link-local addresses and init data type |
Date: | 2016-05-30 04:37:56 |
Message-ID: | 39FCD58F-B318-43BE-8FEE-4345AA94BCD8@tomd.cc |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi all
I just ran into an issue that was originally reported way back in 2007 - https://www.postgresql.org/message-id/flat/0262B803-B664-4EBE-85B4-3C9A40EA6CDA(at)mobygames(dot)com <https://www.postgresql.org/message-id/flat/0262B803-B664-4EBE-85B4-3C9A40EA6CDA(at)mobygames(dot)com>
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?
Cheers
Tom
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Meskes | 2016-05-30 07:51:07 | Re: Question and suggestion about application binary compatibility policy |
Previous Message | Michael Paquier | 2016-05-30 03:51:17 | Re: [GENERAL] Permission Denied Error on pg_xlog/RECOVERYXLOG file |