Haribabu Kommi <kommi.harib...@gmail.com> writes: > On Wed, Nov 23, 2016 at 1:42 AM, Tom Lane <t...@sss.pgh.pa.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 -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers