>> 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.
