Re: mac.c - Mailing list pgsql-hackers

From Thomas Lockhart
Subject Re: mac.c
Date
Msg-id 398ED87B.F9CF9E28@alumni.caltech.edu
Whole thread Raw
In response to Re: mac.c  (Larry Rosenman <ler@lerctr.org>)
Responses RE: mac.c  ("Larry Rosenman" <ler@lerctr.org>)
List 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 by date:

Previous
From: Tom Lane
Date:
Subject: Re: [GENERAL] Trouble with float4 after upgrading from 6.5.3 to 7.0.2
Next
From: Lamar Owen
Date:
Subject: Re: was: bad datatypes time and timestamp - wrong gcc option