Skip site navigation (1) Skip section navigation (2)

Re: MACADDR parsing issues

From: Matthijs Bomhoff <matthijs(at)quarantainenet(dot)nl>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: MACADDR parsing issues
Date: 2011-06-06 14:54:26
Message-ID: 27A4258B-BC45-4D75-84CA-377239500CA7@quarantainenet.nl (view raw or flat)
Thread:
Lists: pgsql-bugs
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

In response to

pgsql-bugs by date

Next:From: David FetterDate: 2011-06-06 16:41:01
Subject: Re: BUG #6051: wCTE query fail with wrong error text on a table with rules
Previous:From: Tom LaneDate: 2011-06-06 14:31:50
Subject: Re: MACADDR parsing issues

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group