|From:||Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com>|
|To:||Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>|
|Cc:||Robert Haas <robertmhaas(at)gmail(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net>, Shay Rojansky <roji(at)roji(dot)org>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Vitaly Burovoy <vitaly(dot)burovoy(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Julien Rouhaud <julien(dot)rouhaud(at)dalibo(dot)com>, Craig Ringer <craig(at)2ndquadrant(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>|
|Subject:||Re: macaddr 64 bit (EUI-64) datatype support|
|Views:||Raw Message | Whole Thread | Download mbox|
On Wed, Nov 23, 2016 at 12:53 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> 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.
Thanks for your feedback.
Here is attached updated patch with new datatype "macaddr8" with fixed
of 8 bytes.
If your input a 6 byte MAC address, it automatically converts it into an 8
MAC address by adding the reserved keywords and store it as an 8 byte
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
6 byte addresses.
Test and doc changes are also added.
|Next Message||Alvaro Herrera||2016-11-25 02:31:26||Re: patch: function xmltable|
|Previous Message||Robert Haas||2016-11-25 01:33:37||Re: DISTINCT with btree skip scan|