Thread: ipv4 data type does not allow to use % as subnet mask delimiter

Windows uses % as subnet mask delimiter.

Trying to use it like

create temp table test (test inet) on commit drop;
insert into test values('fe80::f1ea:f3f4:fb48:7155%10')

returns error

ERROR:  invalid input syntax for type inet: "fe80::f1ea:f3f4:fb48:7155%10"
LINE 2: insert into test values('fe80::f1ea:f3f4:fb48:7155%10')


How to fix ?

Andrus.

On tor, 2010-11-11 at 20:33 +0200, Andrus wrote:
> Windows uses % as subnet mask delimiter.

This is not a subnet mask but a zone index, but it should probably still
be supported.

Peter Eisentraut <peter_e@gmx.net> writes:
> On tor, 2010-11-11 at 20:33 +0200, Andrus wrote:
>> Windows uses % as subnet mask delimiter.

> This is not a subnet mask but a zone index, but it should probably still
> be supported.

I believe we looked into that some time ago and decided that the
behavior was too platform-dependent to be worth messing with.

            regards, tom lane

On sön, 2010-11-14 at 16:46 -0500, Tom Lane wrote:
> Peter Eisentraut <peter_e@gmx.net> writes:
> > On tor, 2010-11-11 at 20:33 +0200, Andrus wrote:
> >> Windows uses % as subnet mask delimiter.
>
> > This is not a subnet mask but a zone index, but it should probably still
> > be supported.
>
> I believe we looked into that some time ago and decided that the
> behavior was too platform-dependent to be worth messing with.

I suppose the problem is that the zone identifier could be almost any
string, and storing that would upset the inet storage format.

Then again, this is part of the IPv6 standard, so just giving up might
not be sustainable in the long run.

Peter Eisentraut <peter_e@gmx.net> writes:
> On sön, 2010-11-14 at 16:46 -0500, Tom Lane wrote:
>> I believe we looked into that some time ago and decided that the
>> behavior was too platform-dependent to be worth messing with.

> I suppose the problem is that the zone identifier could be almost any
> string, and storing that would upset the inet storage format.

That was one problem --- but since inet is already varlena, I think that
adding a string wouldn't be fatal in itself.  The real problem IMO is
that the specific strings aren't standardized, so an inet value that is
valid on one platform might not be valid on another.  Simple concepts
like comparing for equality also get hard if you don't know how the
platform actually interprets the strings.

> Then again, this is part of the IPv6 standard, so just giving up might
> not be sustainable in the long run.

Possibly someday the standard will actually standardize the things,
and then maybe we can work with them usefully ...

            regards, tom lane

> Possibly someday the standard will actually standardize the things,
> and then maybe we can work with them usefully ...

From http://tools.ietf.org/html/rfc4007#section-11.2

implementation SHOULD
   support the following format:

            <address>%<zone_id>

   where

      <address> is a literal IPv6 address,

      <zone_id> is a string identifying the zone of the address, and

      `%' is a delimiter character to distinguish between <address> and
      <zone_id>.

so this is clearly standardized.
It should be mentioned in docs that PostgreSql does not support ipv6 and
attempt to use will cause crash.

Andrus.

On mån, 2010-11-15 at 11:06 +0200, Andrus wrote:
> > Possibly someday the standard will actually standardize the things,
> > and then maybe we can work with them usefully ...
>
> >From http://tools.ietf.org/html/rfc4007#section-11.2
>
> implementation SHOULD
>    support the following format:
>
>             <address>%<zone_id>
>
>    where
>
>       <address> is a literal IPv6 address,
>
>       <zone_id> is a string identifying the zone of the address, and
>
>       `%' is a delimiter character to distinguish between <address> and
>       <zone_id>.
>
> so this is clearly standardized.

Send a patch please.

Peter Eisentraut <peter_e@gmx.net> writes:
> On mån, 2010-11-15 at 11:06 +0200, Andrus wrote:
>>> Possibly someday the standard will actually standardize the things,
>>> and then maybe we can work with them usefully ...

>> From http://tools.ietf.org/html/rfc4007#section-11.2
>> so this is clearly standardized.

> Send a patch please.

Please note where the above-cited reference says

    The precise format and semantics of additional strings is
    implementation dependent.

The paragraphs following that get even vaguer.  In particular, while
the standard clearly envisions that non-numeric zone ids should be
equivalent to some numeric zone id, the mapping between them is not
specified.  Hence it's impossible to determine validity, let alone
test equality, except by reference to some specific implementation's
behavior.

I really think this is something we shouldn't touch, at least not
till standard practices emerge.

            regards, tom lane