MACADDR parsing issues

Поиск
Список
Период
Сортировка
От Matthijs Bomhoff
Тема MACADDR parsing issues
Дата
Msg-id FAF482C3-B9D4-43DD-9697-0600E97E2FAB@quarantainenet.nl
обсуждение исходный текст
Ответы Re: MACADDR parsing issues  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-bugs
Hey,

While playing around with different MAC address notations supported by postgresql, I encountered the following:


db=> select '08002b-010203'::macaddr;
      macaddr
-------------------
 08:00:2b:01:02:03
(1 row)

db=> select '08002b-01023'::macaddr;
      macaddr
-------------------
 08:00:2b:01:02:03
(1 row)

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

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

(These particular results have been encountered on 8.4.4, but similar issues still seem to exist in the git head I
pulledlast week.) 

Note how for example '08002b-0123' is accepted as a valid MAC and is parsed as '08:00:2b:00:12:03' leading to two
additionalzeroes being added in different places. Furthermore, the last example actually matches the pattern for a MAC
withoutdelimiters, incorrectly parsing "-1" as one of the octets and thus resulting in an error about invalid octets
insteadof an invalid syntax. 

In case anyone is interested, I have attached a simple attempt at a patch for the MAC address parser that makes it a
bitmore strict in such a way that it still accepts the formats specified in the documentation, but rejects many other
"broken"addresses that are currently accepted with sometimes surprising results. The attached version also rejects MACs
containingadditional whitespace between the octets and separators etc. The patch probably still needs a bit of work to
makeit more in line with your coding style, as well as a decent review to make sure it doesn't break anything else, but
I'llleave that to those who know more about postgresql, MAC notations and sscanf :) 

I have also added a couple of additional test cases in the same diff, although the code could still use a few more for
possiblecorner cases etc. 

Regards,

Matthijs Bomhoff

Вложения

В списке pgsql-bugs по дате отправления:

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Re: BUG #6052: ADD COLUMN - ERROR: tables can have at most 1600 columns
Следующее
От: Tom Lane
Дата:
Сообщение: Re: MACADDR parsing issues