mac.c

My concern is what do we use to store the first 3 octets of the
macaddr into the table or how to do the partial match on an existing
macaddr type.

I had tried to respond to this earlier. For some reason, my new dial-in
drop "can not find" some, but not all, mail addresses. Yours is
apparently on the "can't find" list, as is Jan's (yahoo.com *is* pretty
obscure :/

Anyway, tables are good, and we can make a function/operator pair which
compares mac addresses on manufacturer only. Should be pretty easy.
Shall we get started?

- Thomas

My concern is what do we use to store the first 3 octets of the
macaddr into the table or how to do the partial match on an existing
macaddr type.

I had tried to respond to this earlier. For some reason, my new dial-in
drop "can not find" some, but not all, mail addresses. Yours is
apparently on the "can't find" list, as is Jan's (yahoo.com *is* pretty
obscure :/

Hmm. What ISP? (I work for mine, and may be able to help them...).

Anyway, tables are good, and we can make a function/operator pair which
compares mac addresses on manufacturer only. Should be pretty easy.
Shall we get started?

OK, but what do we put into the table as the key? just a
3 octet version of the OUI, or a full 6 octet, and use the function?

Thanks for the help.

- 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

Anyway, tables are good, and we can make a function/operator pair which
compares mac addresses on manufacturer only. Should be pretty easy.
Shall we get started?

OK, but what do we put into the table as the key? just a
3 octet version of the OUI, or a full 6 octet, and use the function?

Thanks for the help.

I hate to pour cold water on this, but it seems the whole idea of
having a database function to find the manufacturer from an ethernet
address is of questionable value.

Not that it can't be done in /contrib, but it is really important enough
to do? I recommend just removing the function. I doubt anyone would
miss it.

I have added a TODO item:

* Update macaddr manufacturer numbers, or remove the function macaddr_manuf()

-- 
  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

All I want to do now (given the size stuff), is to have a function and
possibly a type to compare the 24-bit OUI's, and give the tools
in /contrib to load a table using these from the IEEE's list.

No more hardcoded stuff in the db.

Does this make more sense?

It's definately extensible, and frees code space.

Larry

Anyway, tables are good, and we can make a function/operator pair which
compares mac addresses on manufacturer only. Should be pretty easy.
Shall we get started?

OK, but what do we put into the table as the key? just a
3 octet version of the OUI, or a full 6 octet, and use the function?

Thanks for the help.

I hate to pour cold water on this, but it seems the whole idea of
having a database function to find the manufacturer from an ethernet
address is of questionable value.

Not that it can't be done in /contrib, but it is really important enough
to do? I recommend just removing the function. I doubt anyone would
miss it.

I have added a TODO item:

* Update macaddr manufacturer numbers, or remove the function macaddr_manuf()

-- 
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

--
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

All I want to do now (given the size stuff), is to have a function and
possibly a type to compare the 24-bit OUI's, and give the tools
in /contrib to load a table using these from the IEEE's list.

No more hardcoded stuff in the db.

Does this make more sense?

It's definately extensible, and frees code space.

I was just wondering if there was any real demand for this feature.
-- 
  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

It'd be nice (tm). I am using mac address types now, and certainly going
to be upset if they just disappear in next postgres version :P)

However, this is definitely a contrib feature, not a core postgres item.

Probably the macaddr type should be also moved to that contrib directory.

I suggest that the contrib would include a query that creates mac_manuf
table and a 'macaddr_manuf(macaddr) returns varchar' function which would
do a 'select name from mac_manuf m where m.mac=mac_trunc(macaddr)' and a
'mac_trunc(macaddr) returns macaddr' which would set the 3 lowest-order
nibbles to 0.

(I don't think macmanufacturer deserves a separate type).

-alex

On Wed, 26 Jul 2000, Bruce Momjian wrote:

It'd be nice (tm). I am using mac address types now, and certainly going
to be upset if they just disappear in next postgres version :P)

No, I don't recommend removing the macaddr type. It is fine in the main
tree. It is just the function that maps ethernet address to
manufacturer that I am questioning.

However, this is definitely a contrib feature, not a core postgres item.

Probably the macaddr type should be also moved to that contrib directory.

I suggest that the contrib would include a query that creates mac_manuf
table and a 'macaddr_manuf(macaddr) returns varchar' function which would
do a 'select name from mac_manuf m where m.mac=mac_trunc(macaddr)' and a
'mac_trunc(macaddr) returns macaddr' which would set the 3 lowest-order
nibbles to 0.

(I don't think macmanufacturer deserves a separate type).

-- 
  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

On Thu, 27 Jul 2000, Bruce Momjian wrote:

It'd be nice (tm). I am using mac address types now, and certainly going
to be upset if they just disappear in next postgres version :P)

No, I don't recommend removing the macaddr type. It is fine in the main
tree. It is just the function that maps ethernet address to
manufacturer that I am questioning.

sounds to me like a contrib item too ...

However, this is definitely a contrib feature, not a core postgres item.

Probably the macaddr type should be also moved to that contrib directory.

I suggest that the contrib would include a query that creates mac_manuf
table and a 'macaddr_manuf(macaddr) returns varchar' function which would
do a 'select name from mac_manuf m where m.mac=mac_trunc(macaddr)' and a
'mac_trunc(macaddr) returns macaddr' which would set the 3 lowest-order
nibbles to 0.

(I don't think macmanufacturer deserves a separate type).

-- 
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

Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org

At 11:54 PM -0400 7/26/00, Bruce Momjian wrote:

All I want to do now (given the size stuff), is to have a function and
possibly a type to compare the 24-bit OUI's, and give the tools
in /contrib to load a table using these from the IEEE's list.

No more hardcoded stuff in the db.

Does this make more sense?

It's definately extensible, and frees code space.

I was just wondering if there was any real demand for this feature.

Seems to me that code to deal with 24/48 bit integers is core, and
everything else is contrib. The actual list of manufacturers is not
even Postgres, but IEEE and should have a URL or cross reference in
contrib.

Just my opinion.

Signature failed Preliminary Design Review.
Feasibility of a new signature is currently being evaluated.
h.b.hotz@jpl.nasa.gov, or hbhotz@oxy.edu