On Sat, Jun 4, 2016 at 1:50 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> Robert Haas <robertmh...@gmail.com> writes:
>> Yeah, but what if somebody doesn't want to store scopes?
> [ shrug... ]  We can invent a "strip_scope()" sort of function,
> analogous to the weight-stripping function for tsvectors, or several
> other examples.  That's a really lame excuse for not being *able*
> to store scopes.
>> ff::1%fourscoreandsevenyearsagoourforefathersbroughtforthonthiscontinentanewnationconceivedinlibertyanddedicatedtothepropositionthatlallmenarecreatedequal
> 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.

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 

windows - fe80::3%1
unix systems - fe80::3%eth0

>From [2], the maximum interface name allowed in linux is 16 bytes and windows
256 bytes. Any way for windows the zone id is a number index to the interface.

I added another character array of 256 member into inet_struct as a last member
to store the zone id. Modified the inet_cidr_pton_ipv6 function to handle '%'.
Currently all the printable characters are treated as zone id's. I
will restrict this
to only alphabets and numbers.

Here I attached POC patch that adds the support of storing ipv6 with scope id
in the inet datatype.

Approach of adding the member to the structure and storing is fine or any better
way to handle the same? If we come to an conclusion on the approach, i will
add the zone support for everything and send the patch.

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
Do we need to throw an error in this case or just ignore.

[1] - 
[2] - 

Hari Babu
Fujitsu Australia

Attachment: ipv6_scopeid_poc.patch
Description: Binary data

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

Reply via email to