Re: MACADDR parsing issues

On Jun 6, 2011, at 4:31 PM, Tom Lane wrote:

> Matthijs Bomhoff <matthijs(at)quarantainenet(dot)nl> writes:
>> The attached version also rejects MACs containing additional
>> whitespace between the octets and separators etc.
>
> I was under the impression that allowing whitespace there was a feature,
> not a bug.

Ah, I was not sure about that, that's why I explicitly mentioned it.

In my patch I disallowed whitespace on both sides of the separators, as "01:02:03:04:05: 06" is currently fine, but "01:02:03:04:05 :06" is not, so I thought this might simply have been an unintended consequence of using sscanf. This could of course be changed in my patch.

> I'm not sure about the more general question of which
> abbreviated MAC formats are or should be allowed, though. Can you point
> to any standards about that? I'm disinclined to incur the inevitable
> application-compatibility complaints from making the code reject things
> it now accepts unless we have a pretty solid argument that "it now acts
> more like RFC NNNN says it should".

According to the postgres documentation for the MACADDR data type, "The remaining four input formats are not part of any standard.", and I haven't been able to find any evidence to the contrary regarding that during a quick search. I do think some network hardware vendors allow some abbreviated formats, while others don't. Although I am by no means an expert on this, that's why I mentioned someone with more knowledge of such notations should probably look at it.

I understand and agree that backwards-compatibility is a good thing, however I was personally rather surprised to see this happen:

db=> select '08002b-0123'::macaddr;
macaddr
-------------------
08:00:2b:00:12:03

I can't imagine anyone writing an application that counts on this behavior (turning "0123" into "001203"; I am inclined not to qualify that as abbreviation.), in particular as the following leads to an error:

db=> select '08002b-1203'::macaddr;
ERROR: invalid octet value in "macaddr" value: "08002b-1203"
LINE 1: select '08002b-1203'::macaddr;
^

Anyway, I only wanted to point this out as some of the current behavior struck me as slightly odd. And I figured it would be nice to add a possible patch and some additional tests to my email in order to help out a bit in case anyone thought it would be a good idea to change it. Do with it as you see fit :)

Regards,

Matthijs Bomhoff