On Wed, Nov 23, 2016 at 1:42 AM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> Haribabu Kommi <kommi.harib...@gmail.com> writes:
> > Any suggestions for the name to be used for the new datatype the can
> > work for both 48 and 64 bit MAC addresses?
> 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.
> > It is possible to represent a 48 bit MAC address as 64 bit MAC address
> > by adding reserved bytes in the middle as follows.
> > 01-01-01-01-01-01::macaddr => 01-01-01-FF-FE-01-01-01::newmacaddr
> Check. So we could accept 6-byte addresses on input and perform
> that conversion automatically.
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
> > While comparing a 48 bit MAC address with 64 bit MAC address, Ignore
> > the two bytes if the contents in those bytes are reserved bytes.
> Um ... I don't follow. Surely these must compare different:
Yes, that's correct. Both the above MAC addresses are different.
Sorry for not providing more details.
The new macaddr8 datatype can accept both 6 and 8 byte MAC addresses.
Let's assume the data in the table for the macaddr8 column as follows.
row1 = 01-01-01-02-02-02
row2 = 01-01-01-FF-FE-02-02-02
The MAC address is same, it is just a representation in 2 forms, one is 6
and another is 8 byte.
What I am suggesting is, we can treat both of the rows data as same, because
it is just a representation difference.
To do the same, while comparing two MAC addresses that are of 6 and 8 byte
length, some special handling is added to check for the reserved keywords
the 8 byte MAC address, based on that the comparison is carried out.
> The new datatype can store directly whatever is the input is, like 48 bit
> > or 64 bit. The same data is sent over the wire, whether the reserved
> > bytes are present or not?
> I'd just send all 8 bytes. What the client wants to do with values
> that could be mapped back into the 6-byte space is its business.
As the new datatype that can store both 6 and 8 byte MAC addresses
as it is, while sending this data to client, based on the data that is
it sends 6 or 8 bytes.
If we go with storing 8 byte always, then sending all 8 bytes is fine.