On Thu, Oct 13, 2016 at 7:59 AM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> Alvaro Herrera <alvhe...@2ndquadrant.com> writes: > > Tom Lane wrote: > >> Vitaly Burovoy <vitaly.buro...@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. > > Thanks for all your opinions regarding the addition of new datatype to support EUI-64 Mac address, I will work on it and come up with a patch. Regards, Hari Babu Fujitsu Australia
