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