Re: macaddr 64 bit (EUI-64) datatype support
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: Vitaly Burovoy <vitaly.burovoy@gmail.com>,
Julien Rouhaud <julien.rouhaud@dalibo.com>,
Craig Ringer <craig@2ndquadrant.com>,
Haribabu Kommi <kommi.haribabu@gmail.com>,
"pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2016-10-12T20:59:43Z
Lists: pgsql-hackers
Alvaro Herrera <alvherre@2ndquadrant.com> writes: > Tom Lane wrote: >> Vitaly Burovoy <vitaly.burovoy@gmail.com> writes: >>> P.S.: I still think it is a good idea to change storage format, >> I'm not sure which part of "no" you didn't understand, but we're >> not breaking on-disk compatibility of existing macaddr columns. >> Breaking the on-the-wire binary I/O representation seems like a >> nonstarter as well. > I think the suggestion was to rename macaddr to macaddr6 or similar, > keeping the existing behavior and the current OID. So existing columns > would continue to work fine and maintain on-disk compatibility, but any > newly created columns would become the 8-byte variant. ... and would have different I/O behavior from before, possibly breaking applications that expect "macaddr" to mean what it used to. I'm still dubious that that's a good idea. The larger picture here is that we got very little thanks when we squeezed IPv6 into the pre-existing inet datatype; there's a large number of people who just said "no thanks" and started using the add-on ip4r type instead. So I'm not sure why we want to complicate our lives in order to make macaddr follow the same path. regards, tom lane
Commits
-
Add support for EUI-64 MAC addresses as macaddr8
- c7a9fa399d55 10.0 landed
-
perltidy pg_dump TAP tests
- 6af8b89adba1 10.0 cited