On Tue, Nov 22, 2016 at 5:33 AM, Robert Haas <robertmh...@gmail.com> wrote:

> On Sat, Nov 19, 2016 at 2:54 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> > Stephen Frost <sfr...@snowman.net> writes:
> >> Let's create a new data type for this which supports old and new types,
> >> add what casts make sense, and call it a day.  Changing the data type
> >> name out from under people is not helping anyone.
> >
> > +1.  I do not think changing behavior for the existing type name is
> > going to be a net win.  If we'd been smart enough to make the type
> > varlena from the get-go, maybe we could get away with it, but there
> > is just way too much risk of trouble with a change in a fixed-length
> > type's on-the-wire representation.
> I completely agree.

OK. Agreed.

Any suggestions for the name to be used for the new datatype the can
work for both 48 and 64 bit MAC addresses?

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

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.

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?

Hari Babu
Fujitsu Australia

Reply via email to