On 07.06.2016 07:19, Haribabu Kommi wrote:
>> I have not looked at the spec, but I wouldn't be surprised if there
>> were an upper limit on the length of valid scope names.

Yeah, I didn't find any upper limit, either.

> I am not able to find any link that suggests the maximum length of the scope 
> id.
> From [1], I came to know that, how the scope id is formed in different 
> operating
> systems.
> windows - fe80::3%1
> unix systems - fe80::3%eth0

eth0 may well be interface number 1 on some machine, therefore being
equivalent. However, as discussed before, Postgres cannot know, so it
shouldn't bother.

> I added another character array of 256 member into inet_struct as a last 
> member
> to store the zone id.

I haven't looked at the patch in detail, but zeroing or memcpy'ing those
256 bytes seems like overkill to me. I'd recommend to limit this to only
allocate and move around as many bytes as needed for the scope id.

> Currently all the printable characters are treated as zone id's. I
> will restrict this
> to only alphabets and numbers.

I fear alphanumeric only is too restrictive. RFC 4007 only specifies
that the zone id "must not conflict with the delimiter character" and
leaves everything beyond that to the implementation (which seems too
loose, printable characters sounds about right to me...).

> i will add the zone support for everything and send the patch.

What's currently missing?

> How about the following case, Do we treat them as same or different?
> select 'fe80::%eth1'::inet = 'fe80::%ETH1'::inet;

Let's be consistent in not interpreting the scope id in any way, meaning
those would be different. (After all, interfaces names seem to be case
sensitive - on my variant of Linux at the very least - i.e. ETH1 cannot
be found, while eth1 can be.)

> 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 didn't find any evidence for the second case being invalid; nor for it
being valid.

Note, however, that RFC 4007 only gives recommendations for textual
representations (with a "should" preference for the former).

It explicitly "does not specify how the format for non-global addresses
should be combined with the preferred format for literal IPv6 addresses".

Also note that RFC 2732 (Format for Literal IPv6 Addresses in URL's)
doesn't have the '%' sign in the set of reserved characters (not even in
the "unwise" one).

I'm starting to question if it's really wise to add the scope id to the
INET6 type...

> [2] - 
> http://stackoverflow.com/questions/24932172/what-length-can-a-network-interface-name-have

Note that the scope id doesn't necessarily have to be a network
interface name. Concluding there's at max 256 bytes, just because that's
the network interface name's max, doesn't seem correct. However, I agree
that's a reasonable limit for a scope id of the inet6 data type.

Kind Regards

Markus Wanner

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to