Tom Dunstan <pg...@tomd.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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
