On Wed, Nov 23, 2016 at 12:53 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> 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. > Thanks for your feedback. Here is attached updated patch with new datatype "macaddr8" with fixed length of 8 bytes. If your input a 6 byte MAC address, it automatically converts it into an 8 byte MAC address by adding the reserved keywords and store it as an 8 byte address. While sending it to client it always send an 8 byte MAC address. Currently the casting is supported from macaddr to macaddr8, but not the other way. This is because, not all 8 byte MAC addresses can be converted into 6 byte addresses. Test and doc changes are also added. comments? Regards, Hari Babu Fujitsu Australia
mac_eui64_support_2.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
