Re: macaddr 64 bit (EUI-64) datatype support

Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com> writes:
> On Wed, Nov 23, 2016 at 1:42 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> The precedent of int4/int8/float4/float8 is that SQL data types should
>> be named after their length in bytes. So I'd be inclined to call this
>> "macaddr8" not "macaddr64". That would suggest taking the simple
>> approach of always storing values in the 8-byte format, rather than
>> dealing with the complexities of having two formats internally, two
>> display formats, etc.

> Do you prefer the automatic conversion from 6 byte to 8 byte MAC address,
> This way it takes extra space with new datatype. Is it fine to with new
> datatype?

Well, I think the space savings would be pretty illusory. If we use a
varlena datatype, then old-style MAC addresses would take 7 bytes and
new-style would take 9. That's not much of an improvement over always
taking 8 bytes. What's worse, if the next field has an alignment
requirement more than char, is that it's really 8 bytes and 12 bytes (or
16!), making this strictly worse than a fixed-length-8-bytes approach.

As against that, if we use a varlena type then we'd have some protection
against the day when the MAC people realize they were still being
short-sighted and go up to 10 or 12 or 16 bytes. But even if that happens
while Postgres is still in use, I'm not sure that we'd choose to make use
of the varlena aspect rather than invent a third datatype to go with that
new version of the standard. Per the discussion in this thread, varlena
storage in itself doesn't do very much for the client-side compatibility
issues. Making a new datatype with a new, well-defined I/O behavior
ensures that applications don't get blindsided by a new behavior they're
not ready for.

In short, I'm leaning to having just a fixed-length-8-byte implementation.
This may seem like learning nothing from our last go-round, but the
advantages of varlena are very far in the hypothetical future, and the
disadvantages are immediate.

Also, if we define macaddr as "always 6 bytes" and macaddr8 as "always 8
bytes", then there's a very simple way for users to widen an old-style
address to 8 bytes or convert it back to the 6-byte format: just cast
to the other datatype. If the new macaddr type can store both widths
then you need to invent at least one additional function to provide
those behaviors.

regards, tom lane