Re: IPv6 link-local addresses and init data type

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Markus Wanner <markus(at)bluegap(dot)ch>
Cc: Andreas Karlsson <andreas(at)proxel(dot)se>, Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com>, Tom Dunstan <pgsql(at)tomd(dot)cc>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: IPv6 link-local addresses and init data type
Date: 2016-06-03 16:55:41
Message-ID: 639.1464972941@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Markus Wanner <markus(at)bluegap(dot)ch> 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 reboot compared to interface
> indices. Therefore, I'd advocate resolving interface indices (if given)
> to interface names using if_indextoname(3) and let INET types store only
> names.

What will you do on machines without if_indextoname()? 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.

I think a better plan is just to store the zone string verbatim. It is
not our job to check its validity or try to determine which spellings
are equivalent.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2016-06-03 16:57:30 Re: [DOC][PATCH]bloom index options limits
Previous Message Konstantin Knizhnik 2016-06-03 16:50:46 Re: array of domain types