Re: macaddr 64 bit (EUI-64) datatype support

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
Date: 2016-11-25 02:05:24
Views: Raw Message | Whole Thread | Download mbox
Lists: pgsql-hackers

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.


Hari Babu
Fujitsu Australia

Attachment Content-Type Size
mac_eui64_support_2.patch application/octet-stream 51.6 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
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