Thread: BUG #6651: macaddr length constraint violates standard

BUG #6651: macaddr length constraint violates standard

From
erlkonig@talisman.org
Date:
The following bug has been logged on the website:

Bug reference:      6651
Logged by:          Alex North-Keys
Email address:      erlkonig@talisman.org
PostgreSQL version: 9.1.3
Operating system:   any
Description:=20=20=20=20=20=20=20=20

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.

Re: BUG #6651: macaddr length constraint violates standard

From
Peter Eisentraut
Date:
On fre, 2012-05-18 at 19:57 +0000, erlkonig@talisman.org wrote:
> 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".

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?

> Given compatibility concerns, renaming
> it is probably infeasible.  However, being able to parameterize the
> length, defaulting to 6 bytes, would be adequate.

That could be a workable solution.

Re: BUG #6651: macaddr length constraint violates standard

From
Tom Lane
Date:
Peter Eisentraut <peter_e@gmx.net> writes:
> On fre, 2012-05-18 at 19:57 +0000, erlkonig@talisman.org wrote:
>> Given compatibility concerns, renaming
>> it is probably infeasible.  However, being able to parameterize the
>> length, defaulting to 6 bytes, would be adequate.

> That could be a workable solution.

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