The following bug has been logged on the website:

Bug reference: 6651
Logged by: Alex North-Keys
Email address: erlkonig (AT) talisman (DOT) org
PostgreSQL version: 9.1.3
Operating system: any
Description:

The macaddr type does not allow for MACs of greater length (or less than)
than six bytes, only capturing a particular variety of ethernet address
(Xerox's original version) instead of the broader use of MACs where
addresses of other lengths are common, such as the 64-bit EUI-64.

A more appropriate type name would have been "ethernet", specific to the
case actually captured by "macaddr". Given compatibility concerns, renaming
it is probably infeasible. However, being able to parameterize the length,
defaulting to 6 bytes, would be adequate.



--
Sent via pgsql-bugs mailing list (pgsql-bugs (AT) postgresql (DOT) org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

On fre, 2012-05-18 at 19:57 +0000, erlkonig (AT) talisman (DOT) org wrote:
The documentation makes reference to IEEE Std 820, which clearly allows
only 48 bit quantities and calls them "LAN MAC addresses". So I think
the implementation, documentation, and terminology is correct.

I'm not familiar with the EUI-64 space, but the Wikipedia page
http://en.wikipedia.org/wiki/Mac_address indicates that they are related
to but distinct from what is generally known as MAC addresses. But
since you are claiming a standards violation, would you also point out
which standard?

That could be a workable solution.



--
Sent via pgsql-bugs mailing list (pgsql-bugs (AT) postgresql (DOT) org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Peter Eisentraut <peter_e (AT) gmx (DOT) net> writes:
That's far more easily said than done, considering macaddr is a
fixed-length type with essentially no overhead info. I don't see a way
to do this at all without an on-disk compatibility break. Given the
number of requests so far (viz, one) it doesn't seem like something
we should expend much effort on. We might at some point consider
introducing a different type that could handle variable length data
.... although it's not clear that text or bytea couldn't meet the
apparently limited need.

regards, tom lane

--
Sent via pgsql-bugs mailing list (pgsql-bugs (AT) postgresql (DOT) org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs