> > > > I'm not sure whether my long post made it to the list, so I created
> > > > a tarball of the patch and the awk script:
> > > >
> > > > ftp://ftp.lerctr.org/postgresql-patches/macupdate.tar.gz
> > > >
> > > > This has the patch file for mac.c to update the manufacturer list with
> > > > the current list from IEEE and the awk script I ran against the IEEE's
> > > > oui.txt file.
> > > >
> > > > This patch is relative to 7.0.0, but the file is the same in 7.0.2
> > > > the MD5 checksums are identical).
> 
> In looking at this patch, it changes mac.c from:
> 
>     8513 mac.c
>   184323 mac.c.new
> 
> 
> This seems like a major size increase.  Is it worth it to get
> card manufacturers?

Given that our list is old, and the new list is large, does anyone
really want this feature.  It allows the lookup of an ethernet card
manufacturer based on the ethernet MAC address.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Mon, 17 Jul 2000 14:42:53 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Update: mac.c update, patch now on ftp
Bruce Momjian <pgman@candle.pha.pa.us> writes:
>> In looking at this patch, it changes mac.c from:
>> 
>> 8513 mac.c
>> 184323 mac.c.new

Yipes.

>> This seems like a major size increase.  Is it worth it to get
>> card manufacturers?

> Given that our list is old, and the new list is large, does anyone
> really want this feature.  It allows the lookup of an ethernet card
> manufacturer based on the ethernet MAC address.

Seems like hardwiring the lookup table in the server code is
fundamentally wrongheaded anyway.  It should have been designed as
(wait for it...) a database table lookup.

I'd suggest maybe this feature should be offered as a contrib item
containing a database table dump and a simple lookup function
coded in SQL.  Lots easier to maintain, and it doesn't bloat the
backend for people who don't need it.

			regards, tom lane

Mon, 17 Jul 2000 17:46:01 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: Update: mac.c update, patch now on ftp 
I just don't have the smarts to do the code for the backend. 

(strange thought:
 include my ouiparse.awk (changed to generate SQL inserts), and
 does macaddr support like xx:xx:xx% lookups? if so, give them
 the tool to make their own DB.). 

 The code in mac.c does a LINEAR search, and the list is only going to
 grow.  It's at 4110+ OUI's that are PUBLIC.). 

 Larry
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> >> In looking at this patch, it changes mac.c from:
> >> 
> >> 8513 mac.c
> >> 184323 mac.c.new
> 
> Yipes.
> 
> >> This seems like a major size increase.  Is it worth it to get
> >> card manufacturers?
> 
> > Given that our list is old, and the new list is large, does anyone
> > really want this feature.  It allows the lookup of an ethernet card
> > manufacturer based on the ethernet MAC address.
> 
> Seems like hardwiring the lookup table in the server code is
> fundamentally wrongheaded anyway.  It should have been designed as
> (wait for it...) a database table lookup.
> 
> I'd suggest maybe this feature should be offered as a contrib item
> containing a database table dump and a simple lookup function
> coded in SQL.  Lots easier to maintain, and it doesn't bloat the
> backend for people who don't need it.
> 
> 			regards, tom lane


-- 
Larry Rosenman                      http://www.lerctr.org/~ler
Phone: +1 972-414-9812 (voice) Internet: ler@lerctr.org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749

Mon, 17 Jul 2000 20:55:40 -0500 (CDT)
Larry Rosenman <ler@lerctr.org>
Re: Update: mac.c update, patch now on ftp
>  The code in mac.c does a LINEAR search, and the list is only going to
>  grow.  It's at 4110+ OUI's that are PUBLIC.).

Yuck. Let's put it into a (user loadable) table. And rather than having
macaddr_manuf(), we should just have a "sametype()" (or whatever) which
can compare an arbitrary mac address with another one. Then

  select brand from mactypes where '03:04:...' = macmask;

or at least

  select brand from mactypes where sametype('03:04:...',macmask);

would get you the right thing.

I can help with these internals, if that is the right way to head.

                    - Thomas

Tue, 18 Jul 2000 02:54:51 +0000
Thomas Lockhart <lockhart@alumni.caltech.edu>
Re: Update: mac.c update, patch now on ftp
I was thinking of making the following:

1) macaddr_manuf function that returns the first 3 octets of a macaddr
2) a macaddr_manuf TYPE that can be used for the table
3) supply the ouiparse.awk to generate a set of INSERT statements
   to load a table
4) allow the above table to be indexed. 

What does the group think of this?

Larry Rosenman
> >  The code in mac.c does a LINEAR search, and the list is only going to
> >  grow.  It's at 4110+ OUI's that are PUBLIC.).
> 
> Yuck. Let's put it into a (user loadable) table. And rather than having
> macaddr_manuf(), we should just have a "sametype()" (or whatever) which
> can compare an arbitrary mac address with another one. Then
> 
>   select brand from mactypes where '03:04:...' = macmask;
> 
> or at least
> 
>   select brand from mactypes where sametype('03:04:...',macmask);
> 
> would get you the right thing.
> 
> I can help with these internals, if that is the right way to head.
> 
>                     - Thomas


-- 
Larry Rosenman                      http://www.lerctr.org/~ler
Phone: +1 972-414-9812 (voice) Internet: ler@lerctr.org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749

Tue, 18 Jul 2000 06:50:25 -0500 (CDT)
Larry Rosenman <ler@lerctr.org>
Re: Update: mac.c update, patch now on ftp
> I was thinking of making the following:
> 1) macaddr_manuf function that returns the first 3 octets of a macaddr
> 2) a macaddr_manuf TYPE that can be used for the table
> 3) supply the ouiparse.awk to generate a set of INSERT statements
>    to load a table
> 4) allow the above table to be indexed.

Why not use a comparison function which knows how to compare just the
manufacturer's id fields? Or define a function which masks a mac address
to return the id fields and zeros everywhere else (so you can then use
the "normal" comparison functions)?

Defining a new type to allow this masking and comparison seems more than
necessary (which, if this argument holds up, would make it undesirable).
We can still define functional indices so that a table lookup will be
fast in any case.

                       - Thomas

Thu, 20 Jul 2000 06:07:38 +0000
Thomas Lockhart <lockhart@alumni.caltech.edu>
Re: Update: mac.c update, patch now on ftp
Ok, how would one set this up (I've NEVER programmed in PG's backend,
so I'm a little skittish). 

The changes I did for mac.c were obvious, so I'm afraid of breaking
PG's world. 

Anything I can do?

Larry
> > I was thinking of making the following:
> > 1) macaddr_manuf function that returns the first 3 octets of a macaddr
> > 2) a macaddr_manuf TYPE that can be used for the table
> > 3) supply the ouiparse.awk to generate a set of INSERT statements
> >    to load a table
> > 4) allow the above table to be indexed.
> 
> Why not use a comparison function which knows how to compare just the
> manufacturer's id fields? Or define a function which masks a mac address
> to return the id fields and zeros everywhere else (so you can then use
> the "normal" comparison functions)?
> 
> Defining a new type to allow this masking and comparison seems more than
> necessary (which, if this argument holds up, would make it undesirable).
> We can still define functional indices so that a table lookup will be
> fast in any case.
> 
>                        - Thomas


-- 
Larry Rosenman                      http://www.lerctr.org/~ler
Phone: +1 972-414-9812 (voice) Internet: ler@lerctr.org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749

Thu, 20 Jul 2000 01:33:33 -0500 (CDT)
Larry Rosenman <ler@lerctr.org>
Re: Update: mac.c update, patch now on ftp