Horton

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

Jon Nelson <jnelson+pgsql@jamponi.net>

View thread View on postgr.es
From: Jon Nelson <jnelson+pgsql@jamponi.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Haribabu Kommi <kommi.haribabu@gmail.com>, Robert Haas <robertmhaas@gmail.com>, Stephen Frost <sfrost@snowman.net>, Shay Rojansky <roji@roji.org>, Peter Eisentraut <peter.eisentraut@2ndquadrant.com>, Vitaly Burovoy <vitaly.burovoy@gmail.com>, Alvaro Herrera <alvherre@2ndquadrant.com>, Julien Rouhaud <julien.rouhaud@dalibo.com>, Craig Ringer <craig@2ndquadrant.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2016-11-22T17:37:26Z
Lists: pgsql-hackers 
On Tue, Nov 22, 2016 at 8: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.
>

Be that as it may, but almost everybody else (outside the db world?) uses
bits.  The C types, for example, are expressed in bits (int8_t, int64_t,
etc...).

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

What's more, it now requires 2 comparisons and some logic versus the
possibility of a single memcmp.

-- 
Jon

Commits

  1. Add support for EUI-64 MAC addresses as macaddr8

  2. perltidy pg_dump TAP tests