Re: MACADDR parsing issues

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

> Matthijs Bomhoff <matthijs@quarantainenet.nl> writes:
>> The attached version also rejects MACs containing additional
>> whitespace between the octets and separators etc.
>=20
> 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 ssca=
nf. 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 rem=
aining four input formats are not part of any standard.", and I haven't bee=
n able to find any evidence to the contrary regarding that during a quick s=
earch. I do think some network hardware vendors allow some abbreviated form=
ats, 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 pro=
bably look at it.

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

db=3D> 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 abbrevi=
ation.), in particular as the following leads to an error:

db=3D> 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 str=
uck me as slightly odd. And I figured it would be nice to add a possible pa=
tch and some additional tests to my email in order to help out a bit in cas=
e anyone thought it would be a good idea to change it. Do with it as you se=
e fit :)

Regards,

Matthijs Bomhoff