Re: [HACKERS] IPv6 link-local addresses and init data type

Robert Haas writes: > On Wed, Nov 9, 2016 at 9:02 AM, Peter Eisentraut > wrote: >> On 11/7/16 1:13 AM, Haribabu Kommi wrote: >>> Yes, I agree that default zone is the main use case of the original thread. >>> From the RFC 4007, the default

Re: [HACKERS] IPv6 link-local addresses and init data type

On Wed, Nov 9, 2016 at 9:02 AM, Peter Eisentraut wrote: > On 11/7/16 1:13 AM, Haribabu Kommi wrote: >> Yes, I agree that default zone is the main use case of the original thread. >> From the RFC 4007, the default zone is used for the global addresses, >> This may

Re: [HACKERS] IPv6 link-local addresses and init data type

On 11/7/16 1:13 AM, Haribabu Kommi wrote: > Yes, I agree that default zone is the main use case of the original thread. > From the RFC 4007, the default zone is used for the global addresses, > This may be the main use case with zone id. How about currently just > ignoring it and store the actual

Re: [HACKERS] IPv6 link-local addresses and init data type

On Fri, Nov 4, 2016 at 6:33 AM, Peter Eisentraut < peter.eisentr...@2ndquadrant.com> wrote: > 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 =

Re: [HACKERS] IPv6 link-local addresses and init data type

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 >>

Re: [HACKERS] IPv6 link-local addresses and init data type

On Wed, Jun 29, 2016 at 6:31 AM, Markus Wanner wrote: >> 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

Re: [HACKERS] IPv6 link-local addresses and init data type

Haribabu, 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

Re: [HACKERS] IPv6 link-local addresses and init data type

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

Re: [HACKERS] IPv6 link-local addresses and init data type

On Sat, Jun 4, 2016 at 1:50 PM, Tom Lane wrote: > Robert Haas 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

Re: [HACKERS] IPv6 link-local addresses and init data type

Robert Haas 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

Re: [HACKERS] IPv6 link-local addresses and init data type

On Fri, Jun 3, 2016 at 5:02 PM, Tom Lane wrote: > Markus Wanner writes: >> That leaves me wondering if it's really worth extending INET, though. >> TEXT would be just fine to store a textual scope id. And it makes it >> utterly clear that there's no magic

Re: [HACKERS] IPv6 link-local addresses and init data type

Markus Wanner writes: > That leaves me wondering if it's really worth extending INET, though. > TEXT would be just fine to store a textual scope id. And it makes it > utterly clear that there's no magic involved. True, but it would force users to disassemble and reassemble the

Re: [HACKERS] IPv6 link-local addresses and init data type

On 06/03/2016 06:55 PM, Tom Lane wrote: > More importantly, > on what basis do you conclude that the inet type will only be asked to > store link-local addresses that are currently valid on the local machine? > It is not very hard to think of applications where that wouldn't be the > case. That's

Re: [HACKERS] IPv6 link-local addresses and init data type

Markus Wanner writes: > Considering that Postgres is not unlikely to write INET types to > permanent storage, its values should better survive a reboot. And while > I have some doubts about persistence of interface names, those clearly > have a higher chance of surviving a

Re: [HACKERS] IPv6 link-local addresses and init data type

On 06/03/2016 12:14 AM, Tom Lane wrote: > Markus Wanner writes: >> I'm even wondering if 'fe80::1%1'::inet = 'fe80::1%2'::inet shouldn't >> simply yield true. After all, it's the same (non-global) address. > > Surely not? If the zone_ids didn't mean anything, why would the

Re: [HACKERS] IPv6 link-local addresses and init data type

Markus Wanner writes: > Given that a zone_id is a) highly system dependent and b) only ever > meaningful for non-global addresses, I'm wondering what the use case for > storing them is. > I'm even wondering if 'fe80::1%1'::inet = 'fe80::1%2'::inet shouldn't > simply yield

Re: [HACKERS] IPv6 link-local addresses and init data type

On 31.05.2016 12:40, Andreas Karlsson wrote: > On 05/31/2016 04:06 AM, Tom Lane wrote: >> Unless there's a semantic difference between fe80::1%2/64 and >> fe80::1/64%2, this doesn't seem like a big deal to me. > > As far as I can till only fe80::1%2/64 is valid, but I am not 100% sure. According

Re: [HACKERS] IPv6 link-local addresses and init data type

On 05/31/2016 04:06 AM, Tom Lane wrote: Andreas Karlsson writes: On 05/31/2016 02:37 AM, Haribabu Kommi wrote: The % delimiter character is not only used at the end of the IPV6 address, from the RFC document, it is possible as follows also. fe80::%2/64 we need to handle

Re: [HACKERS] IPv6 link-local addresses and init data type

Andreas Karlsson writes: > On 05/31/2016 02:37 AM, Haribabu Kommi wrote: >> The % delimiter character is not only used at the end of the IPV6 address, >> from the RFC document, it is possible as follows also. >> >> fe80::%2/64 >> >> we need to handle both the scenarios, it

Re: [HACKERS] IPv6 link-local addresses and init data type

On 05/31/2016 02:37 AM, Haribabu Kommi wrote: The following is the content of IPV6 representation from RFC 4007 The following addresses fe80::1234 (on the 1st link of the node) ff02::5678 (on the 5th link of the node) ff08::9abc (on the 10th

Re: [HACKERS] IPv6 link-local addresses and init data type

On Tue, May 31, 2016 at 9:35 AM, Tom Dunstan wrote: > >> On 31 May 2016, at 2:07 AM, Tom Lane wrote: >> >> 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

Re: [HACKERS] IPv6 link-local addresses and init data type

> On 31 May 2016, at 2:07 AM, Tom Lane wrote: > > 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. Yeah, we’d have to just

Re: [HACKERS] IPv6 link-local addresses and init data type

Tom Dunstan 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

[HACKERS] IPv6 link-local addresses and init data type

Hi all I just ran into an issue that was originally reported way back in 2007 - https://www.postgresql.org/message-id/flat/0262b803-b664-4ebe-85b4-3c9a40ea6...@mobygames.com Basically the inet data