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;
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 :)
In response to
pgsql-bugs by date
|Next:||From: David Fetter||Date: 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 Lane||Date: 2011-06-06 14:31:50|
|Subject: Re: MACADDR parsing issues |