From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
---|---|
To: | Julien Rouhaud <julien(dot)rouhaud(at)dalibo(dot)com> |
Cc: | Craig Ringer <craig(at)2ndquadrant(dot)com>, Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: macaddr 64 bit (EUI-64) datatype support |
Date: | 2016-10-12 16:19:35 |
Message-ID: | 20161012161935.GA915016@alvherre.pgsql |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Julien Rouhaud wrote:
> On 12/10/2016 14:32, Alvaro Herrera wrote:
> > Julien Rouhaud wrote:
> >
> >> and you can instead make macaddr64 support both format, and provide a
> >> macaddr::macaddr64 cast
> >
> > Having macaddr64 support both formats sounds nice, but how does it work?
> > Will we have to reserve one additional bit to select the representation?
> > That would make the type be 65 bits which is a clear loser IMO.
> >
> > Is it allowed to just leave 16 bits as zeroes which would indicate that
> > the address is EUI48? I wouldn't think so ...
>
> From what I read, you can indicate it's an EUI-48 address by storing
> FF:FF (or FF:FE for MAC-48) in 4th and 5th bytes of the EUI-64 address.
That seems reasonable at first glance; so the new type would be able to
store both 48-bit and 64-bit values, and there would be assignment casts
in both directions and a suite of operators to enable interoperability
of 48-bit values in macaddr8 with values in type macaddr. Right?
(The cast function from macaddr8 to macaddr would raise error if the
4th and 5th bytes are not either FF:FF or FF:FE -- I don't think we can
in practice distinguish EUI-48 from MAC-48 in this context. The cast in
the other direction would have no restriction and should probably always
use FF:FE).
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2016-10-12 16:47:29 | Re: Add PGDLLEXPORT to PG_FUNCTION_INFO_V1 |
Previous Message | Robert Haas | 2016-10-12 16:11:07 | Re: Remove "Source Code" column from \df+ ? |