Re: macaddr 64 bit (EUI-64) datatype support - Mailing list pgsql-hackers

From Tom Lane
Subject Re: macaddr 64 bit (EUI-64) datatype support
Date
Msg-id 32718.1476305983@sss.pgh.pa.us
Whole thread Raw
In response to Re: macaddr 64 bit (EUI-64) datatype support  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Responses Re: macaddr 64 bit (EUI-64) datatype support  (Haribabu Kommi <kommi.haribabu@gmail.com>)
Re: macaddr 64 bit (EUI-64) datatype support  (Vitaly Burovoy <vitaly.burovoy@gmail.com>)
Re: macaddr 64 bit (EUI-64) datatype support  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
List 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



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: macaddr 64 bit (EUI-64) datatype support
Next
From: Vitaly Burovoy
Date:
Subject: Re: macaddr 64 bit (EUI-64) datatype support