On Jun 6, 2011, at 4:31 PM, Tom Lane wrote:
> Matthijs Bomhoff <matth...@quarantainenet.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
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
