On 6/7/16 2:43 PM, Peter Eisentraut wrote:
> On 6/7/16 1:19 AM, Haribabu Kommi wrote:
>> How about the following case, Do we treat them as same or different?
>>
>> select 'fe80::%eth1'::inet = 'fe80::%ETH1'::inet;
>>
>> fe80::%2/64 is only treated as the valid address but not other way as
>> fe80::/64%2.
>> Do we need to throw an error in this case or just ignore.
>
> I suspect questions like these are already solved in someone else's IP
> address type/object/class implementation, and we could look there.
I have been doing some testing and reviewed the RFCs again. I'm having
some second thoughts about this.
I tried the IP address parsing modules in Perl, Python, Ruby, and they
all reject zone IDs.
The Java class java.net.Inet6Address accepts zone IDs, but only numbers
and names actually present on the local host.
RFC 4007 specifies that the zone IDs "should" not be used for global
addresses or the loopback address. The presented patch does not check
for that.
The original message in this thread mentioned an address "::1%0", so
that is not even valid. 0 is supposed to be the default zone, so one
could argue that that can be silently accepted.
A zone ID is only meaningful inside a node. So storing it in a table
without an associated node is meaningless. (compare: storing a time
with time zone without a date)
There are also questions about comparing addresses with zone IDs, such
as in the example at the very top. We don't have a good answer on
whether those addresses should be equal. (My OS seems to think that
interface names are case-insensitive.) Also, since there is no node
associated with the address, it's questionable what equal really means
anyway.
So I'm having doubts that the proposed change to allow any string to be
appended to any address is really sound. This could invite a lot of
shenanigans, where equality comparisons or range operations are
subverted, for example.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services