| 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: | Whole Thread | Raw Message | 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
| 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 |