Re: mac.c

Поиск
Список
Период
Сортировка
От Thomas Lockhart
Тема Re: mac.c
Дата
Msg-id 398ED87B.F9CF9E28@alumni.caltech.edu
обсуждение исходный текст
Ответ на Re: mac.c  (Larry Rosenman <ler@lerctr.org>)
Ответы RE: mac.c  ("Larry Rosenman" <ler@lerctr.org>)
Список pgsql-hackers
> We still need to load a *TABLE* with a 3 byte hex number (at least) for
> the OUI, and a text field for the actual manufacturer (see my posted
> ouiparse.awk script).  How do we store that 3 byte hex number (we don't have
> a type that I'm aware of...)?

We extend those three bytes to a full zero-filled mac address when
filling the table. Is there any downside to that?

> Don't get me wrong, I like your idea, but I'm not sure what it buys us after
> the later suggestions I made of returning a half-zeroed mac...

It buys us a natural way of comparing classes of mac addresses. And we
don't have to invoke any extra functions to do it, so you don't need to
remember an obscure function name. Also, it could be extended to do
simple pattern matching a la the LIKE string code:
 SELECT * FROM t1 WHERE t1.addr LIKE '00:01:23:__:05:%';

btw, are fields "a"-"f" a general convention in labeling mac address
fields? Or is that an artifact of Postgres' definition?
                        - Thomas


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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: [GENERAL] Trouble with float4 after upgrading from 6.5.3 to 7.0.2
Следующее
От: Lamar Owen
Дата:
Сообщение: Re: was: bad datatypes time and timestamp - wrong gcc option