On Wed, Nov 23, 2016 at 1:42 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Haribabu Kommi <kommi.haribabu@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 datatype?
> 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:
01-01-01-FF-FE-01-01-01 01-01-01-FF-0E-01-01-01
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 byte
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 in
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 stored,
it sends 6 or 8 bytes.
If we go with storing 8 byte always, then sending all 8 bytes is fine.
