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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
