RE: mac.c

Ok, that's what ouiparse.awk does now loads the bottom 3 octets as 0's.

As to the a-f, I think that's implementation detail(s).

So what you are saying is to find a manufacturer we'd say:

SELECT manufacturer FROM mac_table WHERE substr(mac_table.oui,1,3) =
substr(your_table.mac,1,3);

?

This still looks stilted to me.

LER

-----Original Message-----
From: lockhart(at)mythos(dot)jpl(dot)nasa(dot)gov
[mailto:lockhart(at)mythos(dot)jpl(dot)nasa(dot)gov]On Behalf Of Thomas Lockhart
Sent: Monday, August 07, 2000 10:41 AM
To: Larry Rosenman
Cc: pgsql-hackers(at)hub(dot)org
Subject: Re: [HACKERS] mac.c

> 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