Re: macaddr 64 bit (EUI-64) datatype support - Mailing list pgsql-hackers

From Tom Lane
Subject Re: macaddr 64 bit (EUI-64) datatype support
Date
Msg-id 18212.1479825764@sss.pgh.pa.us
Whole thread Raw
In response to Re: macaddr 64 bit (EUI-64) datatype support  (Haribabu Kommi <kommi.haribabu@gmail.com>)
Responses Re: macaddr 64 bit (EUI-64) datatype support
Re: macaddr 64 bit (EUI-64) datatype support
List pgsql-hackers
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.

> 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

> 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.

In short, let's just make this work similarly to integers of different
widths, rather than trying to sprinkle extra pixie dust on it.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Erik Rijkers
Date:
Subject: Re: Logical Replication WIP
Next
From: Ashutosh Bapat
Date:
Subject: Re: Push down more full joins in postgres_fdw