mac.c

It appears to me that macaddr_manuf can be defined as this:

macaddr * macaddr_trunc (macaddr *addr)
{
macaddr *result;
if (addr==NULL) return NULL;
result=(macaddr *) palloc(sizeof(struct macaddr));
result->a=addr->a;
result->b=addr->b;
result->c=addr->c;
result->d=0;
result->e=0;
result->f=0;
return result;
}

and then

create function macaddr_trunc(macaddr) returns macaddr as
'MODULE_PATHNAME' language 'c';

and then
create function macaddr_manuf(macaddr) returns varchar2 as '
select name from macaddr_blah where mac=macaddr_trunc($1)
' language 'sql';

Be warned, this code was typed directly in editor and not compiled ;P
Unfortunately, I don't have time to make a full-fledged contrib out of
this and Larry's awk files.

-alex

On Tue, 1 Aug 2000, Larry Rosenman wrote:

Any comments at all from anyone on my mail from Sunday Nite on
making the macaddr_manuf function just return a
masked MACADDR (I.E. set the low 3 bytes to 0x00) and how we
do this in the code?

So macaddr_manuf() will be changed to return a mac address with the low
bytes set to zero? There is certainly a use for a function like this,
along with another function, say ismanuf() or same() or similar() or ??,
which takes two mac addresses and compares just the manufacturer's
fields. Why not call the "manufacturer's mask" function something like
manuf() or brand() or ?? rather than reusing macaddr_manuf() which would
become obsolete?

Any comments on the ouiparse.awk script?

The awk script looks OK (and if anyone objected enough they could
rewrite in perl or whatever). Where does one get the IEEE list it uses?

- Thomas

Any comments at all from anyone on my mail from Sunday Nite on
making the macaddr_manuf function just return a
masked MACADDR (I.E. set the low 3 bytes to 0x00) and how we
do this in the code?

So macaddr_manuf() will be changed to return a mac address with the low
bytes set to zero? There is certainly a use for a function like this,
along with another function, say ismanuf() or same() or similar() or ??,
which takes two mac addresses and compares just the manufacturer's
fields. Why not call the "manufacturer's mask" function something like
manuf() or brand() or ?? rather than reusing macaddr_manuf() which would
become obsolete?

Sure, I just don't want to make a mistake on coding it. I'm open.

Since macaddr_manuf() will not be up to date, I'd say lets make
the new function macaddr_brand, and if someone wants to do the other
two, fine. I'd also doc the fact that macaddr_manuf() is deprecated, marked
for deletion one or two releases down the line (since the table will
no longer be updated, and is very much outdated).

Any comments on the ouiparse.awk script?

The awk script looks OK (and if anyone objected enough they could
rewrite in perl or whatever). Where does one get the IEEE list it uses?

It's on the IEEE site (http://standards.ieee.org/regauth/oui/index.shtml).

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

Any comments at all from anyone on my mail from Sunday Nite on
making the macaddr_manuf function just return a
masked MACADDR (I.E. set the low 3 bytes to 0x00) and how we
do this in the code?

So macaddr_manuf() will be changed to return a mac address with the low
bytes set to zero? There is certainly a use for a function like this,
along with another function, say ismanuf() or same() or similar() or ??,
which takes two mac addresses and compares just the manufacturer's
fields. Why not call the "manufacturer's mask" function something like
manuf() or brand() or ?? rather than reusing macaddr_manuf() which would
become obsolete?

Sure, I just don't want to make a mistake on coding it. I'm open.

Since macaddr_manuf() will not be up to date, I'd say lets make
the new function macaddr_brand, and if someone wants to do the other
two, fine. I'd also doc the fact that macaddr_manuf() is deprecated, marked
for deletion one or two releases down the line (since the table will
no longer be updated, and is very much outdated).

We can delete it in 7.1. No reason to keep it around if the output is
invalid.

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

What about people that are using it? Or will it get noted in the upgrade
path doc?

LER

-----Original Message-----
From: pgsql-hackers-owner@hub.org [mailto:pgsql-hackers-owner@hub.org]On
Behalf Of Bruce Momjian
Sent: Wednesday, August 02, 2000 8:15 AM
To: Larry Rosenman
Cc: Thomas Lockhart; pgsql-hackers@hub.org
Subject: Re: [HACKERS] mac.c

Any comments at all from anyone on my mail from Sunday Nite on
making the macaddr_manuf function just return a
masked MACADDR (I.E. set the low 3 bytes to 0x00) and how we
do this in the code?

So macaddr_manuf() will be changed to return a mac address with the low
bytes set to zero? There is certainly a use for a function like this,
along with another function, say ismanuf() or same() or similar() or ??,
which takes two mac addresses and compares just the manufacturer's
fields. Why not call the "manufacturer's mask" function something like
manuf() or brand() or ?? rather than reusing macaddr_manuf() which would
become obsolete?

Sure, I just don't want to make a mistake on coding it. I'm open.

Since macaddr_manuf() will not be up to date, I'd say lets make
the new function macaddr_brand, and if someone wants to do the other
two, fine. I'd also doc the fact that macaddr_manuf() is deprecated,

marked

for deletion one or two releases down the line (since the table will
no longer be updated, and is very much outdated).

We can delete it in 7.1. No reason to keep it around if the output is
invalid.

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

[ Charset ISO-8859-1 unsupported, converting... ]

What about people that are using it? Or will it get noted in the upgrade
path doc?

There can't be many if it is not working 100%. Better to remove it than
leave an incorrect feature.

LER

-----Original Message-----
From: pgsql-hackers-owner@hub.org [mailto:pgsql-hackers-owner@hub.org]On
Behalf Of Bruce Momjian
Sent: Wednesday, August 02, 2000 8:15 AM
To: Larry Rosenman
Cc: Thomas Lockhart; pgsql-hackers@hub.org
Subject: Re: [HACKERS] mac.c

Any comments at all from anyone on my mail from Sunday Nite on
making the macaddr_manuf function just return a
masked MACADDR (I.E. set the low 3 bytes to 0x00) and how we
do this in the code?

So macaddr_manuf() will be changed to return a mac address with the low
bytes set to zero? There is certainly a use for a function like this,
along with another function, say ismanuf() or same() or similar() or ??,
which takes two mac addresses and compares just the manufacturer's
fields. Why not call the "manufacturer's mask" function something like
manuf() or brand() or ?? rather than reusing macaddr_manuf() which would
become obsolete?

Sure, I just don't want to make a mistake on coding it. I'm open.

Since macaddr_manuf() will not be up to date, I'd say lets make
the new function macaddr_brand, and if someone wants to do the other
two, fine. I'd also doc the fact that macaddr_manuf() is deprecated,

marked

for deletion one or two releases down the line (since the table will
no longer be updated, and is very much outdated).

We can delete it in 7.1. No reason to keep it around if the output is
invalid.

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

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

ok. How do we go about getting this done (I don't trust my skills for the
BE yet...)

LER

-----Original Message-----
From: pgsql-hackers-owner@hub.org [mailto:pgsql-hackers-owner@hub.org]On
Behalf Of Bruce Momjian
Sent: Wednesday, August 02, 2000 8:34 AM
To: Larry Rosenman
Cc: Thomas Lockhart; pgsql-hackers@hub.org
Subject: Re: [HACKERS] mac.c

[ Charset ISO-8859-1 unsupported, converting... ]

What about people that are using it? Or will it get noted in the upgrade
path doc?

There can't be many if it is not working 100%. Better to remove it than
leave an incorrect feature.

LER

-----Original Message-----
From: pgsql-hackers-owner@hub.org [mailto:pgsql-hackers-owner@hub.org]On
Behalf Of Bruce Momjian
Sent: Wednesday, August 02, 2000 8:15 AM
To: Larry Rosenman
Cc: Thomas Lockhart; pgsql-hackers@hub.org
Subject: Re: [HACKERS] mac.c

Any comments at all from anyone on my mail from Sunday Nite on
making the macaddr_manuf function just return a
masked MACADDR (I.E. set the low 3 bytes to 0x00) and how we
do this in the code?

So macaddr_manuf() will be changed to return a mac address with the

low

bytes set to zero? There is certainly a use for a function like this,
along with another function, say ismanuf() or same() or similar() or

??,

which takes two mac addresses and compares just the manufacturer's
fields. Why not call the "manufacturer's mask" function something like
manuf() or brand() or ?? rather than reusing macaddr_manuf() which

would

become obsolete?

Sure, I just don't want to make a mistake on coding it. I'm open.

Since macaddr_manuf() will not be up to date, I'd say lets make
the new function macaddr_brand, and if someone wants to do the other
two, fine. I'd also doc the fact that macaddr_manuf() is deprecated,

marked

for deletion one or two releases down the line (since the table will
no longer be updated, and is very much outdated).

We can delete it in 7.1. No reason to keep it around if the output is
invalid.

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

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

[ Charset ISO-8859-1 unsupported, converting... ]

ok. How do we go about getting this done (I don't trust my skills for the
BE yet...)

I will remove it whenever you want.

LER

-----Original Message-----
From: pgsql-hackers-owner@hub.org [mailto:pgsql-hackers-owner@hub.org]On
Behalf Of Bruce Momjian
Sent: Wednesday, August 02, 2000 8:34 AM
To: Larry Rosenman
Cc: Thomas Lockhart; pgsql-hackers@hub.org
Subject: Re: [HACKERS] mac.c

[ Charset ISO-8859-1 unsupported, converting... ]

What about people that are using it? Or will it get noted in the upgrade
path doc?

There can't be many if it is not working 100%. Better to remove it than
leave an incorrect feature.

LER

-----Original Message-----
From: pgsql-hackers-owner@hub.org [mailto:pgsql-hackers-owner@hub.org]On
Behalf Of Bruce Momjian
Sent: Wednesday, August 02, 2000 8:15 AM
To: Larry Rosenman
Cc: Thomas Lockhart; pgsql-hackers@hub.org
Subject: Re: [HACKERS] mac.c

Any comments at all from anyone on my mail from Sunday Nite on
making the macaddr_manuf function just return a
masked MACADDR (I.E. set the low 3 bytes to 0x00) and how we
do this in the code?

So macaddr_manuf() will be changed to return a mac address with the

low

bytes set to zero? There is certainly a use for a function like this,
along with another function, say ismanuf() or same() or similar() or

??,

which takes two mac addresses and compares just the manufacturer's
fields. Why not call the "manufacturer's mask" function something like
manuf() or brand() or ?? rather than reusing macaddr_manuf() which

would

become obsolete?

Sure, I just don't want to make a mistake on coding it. I'm open.

Since macaddr_manuf() will not be up to date, I'd say lets make
the new function macaddr_brand, and if someone wants to do the other
two, fine. I'd also doc the fact that macaddr_manuf() is deprecated,

marked

for deletion one or two releases down the line (since the table will
no longer be updated, and is very much outdated).

We can delete it in 7.1. No reason to keep it around if the output is
invalid.

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

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

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

I'm also talking about the actual changes as well....

-----Original Message-----
From: pgsql-hackers-owner@hub.org [mailto:pgsql-hackers-owner@hub.org]On
Behalf Of Bruce Momjian
Sent: Wednesday, August 02, 2000 9:28 AM
To: Larry Rosenman
Cc: Thomas Lockhart; pgsql-hackers@hub.org
Subject: Re: [HACKERS] mac.c

[ Charset ISO-8859-1 unsupported, converting... ]

ok. How do we go about getting this done (I don't trust my skills for the
BE yet...)

I will remove it whenever you want.

LER

-----Original Message-----
From: pgsql-hackers-owner@hub.org [mailto:pgsql-hackers-owner@hub.org]On
Behalf Of Bruce Momjian
Sent: Wednesday, August 02, 2000 8:34 AM
To: Larry Rosenman
Cc: Thomas Lockhart; pgsql-hackers@hub.org
Subject: Re: [HACKERS] mac.c

[ Charset ISO-8859-1 unsupported, converting... ]

What about people that are using it? Or will it get noted in the

upgrade

path doc?

There can't be many if it is not working 100%. Better to remove it than
leave an incorrect feature.

LER

-----Original Message-----
From: pgsql-hackers-owner@hub.org [mailto:pgsql-hackers-owner@hub.org]On
Behalf Of Bruce Momjian
Sent: Wednesday, August 02, 2000 8:15 AM
To: Larry Rosenman
Cc: Thomas Lockhart; pgsql-hackers@hub.org
Subject: Re: [HACKERS] mac.c

Any comments at all from anyone on my mail from Sunday Nite on
making the macaddr_manuf function just return a
masked MACADDR (I.E. set the low 3 bytes to 0x00) and how we
do this in the code?

So macaddr_manuf() will be changed to return a mac address with the

low

bytes set to zero? There is certainly a use for a function like

this,

along with another function, say ismanuf() or same() or similar() or

??,

which takes two mac addresses and compares just the manufacturer's
fields. Why not call the "manufacturer's mask" function something

like

manuf() or brand() or ?? rather than reusing macaddr_manuf() which

would

become obsolete?

Sure, I just don't want to make a mistake on coding it. I'm open.

Since macaddr_manuf() will not be up to date, I'd say lets make
the new function macaddr_brand, and if someone wants to do the other
two, fine. I'd also doc the fact that macaddr_manuf() is deprecated,

marked

for deletion one or two releases down the line (since the table will
no longer be updated, and is very much outdated).

We can delete it in 7.1. No reason to keep it around if the output is
invalid.

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

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

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

I'd say lets go for it. do you want me to try and code it, or do you or one
of the others?

-----Original Message-----
From: pgsql-hackers-owner@hub.org [mailto:pgsql-hackers-owner@hub.org]On
Behalf Of Larry Rosenman
Sent: Wednesday, August 02, 2000 9:36 AM
To: Bruce Momjian; Larry Rosenman
Cc: Thomas Lockhart; pgsql-hackers@hub.org
Subject: RE: [HACKERS] mac.c

I'm also talking about the actual changes as well....

-----Original Message-----
From: pgsql-hackers-owner@hub.org [mailto:pgsql-hackers-owner@hub.org]On
Behalf Of Bruce Momjian
Sent: Wednesday, August 02, 2000 9:28 AM
To: Larry Rosenman
Cc: Thomas Lockhart; pgsql-hackers@hub.org
Subject: Re: [HACKERS] mac.c

[ Charset ISO-8859-1 unsupported, converting... ]

ok. How do we go about getting this done (I don't trust my skills for the
BE yet...)

I will remove it whenever you want.

LER

-----Original Message-----
From: pgsql-hackers-owner@hub.org [mailto:pgsql-hackers-owner@hub.org]On
Behalf Of Bruce Momjian
Sent: Wednesday, August 02, 2000 8:34 AM
To: Larry Rosenman
Cc: Thomas Lockhart; pgsql-hackers@hub.org
Subject: Re: [HACKERS] mac.c

[ Charset ISO-8859-1 unsupported, converting... ]

What about people that are using it? Or will it get noted in the

upgrade

path doc?

There can't be many if it is not working 100%. Better to remove it than
leave an incorrect feature.

LER

-----Original Message-----
From: pgsql-hackers-owner@hub.org [mailto:pgsql-hackers-owner@hub.org]On
Behalf Of Bruce Momjian
Sent: Wednesday, August 02, 2000 8:15 AM
To: Larry Rosenman
Cc: Thomas Lockhart; pgsql-hackers@hub.org
Subject: Re: [HACKERS] mac.c

Any comments at all from anyone on my mail from Sunday Nite on
making the macaddr_manuf function just return a
masked MACADDR (I.E. set the low 3 bytes to 0x00) and how we
do this in the code?

So macaddr_manuf() will be changed to return a mac address with the

low

bytes set to zero? There is certainly a use for a function like

this,

along with another function, say ismanuf() or same() or similar() or

??,

which takes two mac addresses and compares just the manufacturer's
fields. Why not call the "manufacturer's mask" function something

like

manuf() or brand() or ?? rather than reusing macaddr_manuf() which

would

become obsolete?

Sure, I just don't want to make a mistake on coding it. I'm open.

Since macaddr_manuf() will not be up to date, I'd say lets make
the new function macaddr_brand, and if someone wants to do the other
two, fine. I'd also doc the fact that macaddr_manuf() is deprecated,

marked

for deletion one or two releases down the line (since the table will
no longer be updated, and is very much outdated).

We can delete it in 7.1. No reason to keep it around if the output is
invalid.

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

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

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

Since macaddr_manuf() will not be up to date, I'd say lets make
the new function macaddr_brand, and if someone wants to do the other
two, fine. I'd also doc the fact that macaddr_manuf() is deprecated, marked
for deletion one or two releases down the line (since the table will
no longer be updated, and is very much outdated).

I've been thinking about this a bit, coincidentally while I've been
working on the LIKE implementation for string comparisons.

Why not implement like() and notlike() for macaddr data types which (if
both args are macaddr) will compare on manufacturer's fields alone? That
would seem to get all the functionality you might want.

Example:

SELECT * FROM machines where hwaddr LIKE
(select id from MacIdCodes where manuf = 'Intel');

or something like that.

That would avoid ginning up something artificial like a macaddr with
some fields zeroed out. We would still have an equality operator etc.

Comments?

- Thomas

Since macaddr_manuf() will not be up to date, I'd say lets make
the new function macaddr_brand, and if someone wants to do the other
two, fine. I'd also doc the fact that macaddr_manuf() is deprecated, marked
for deletion one or two releases down the line (since the table will
no longer be updated, and is very much outdated).

I've been thinking about this a bit, coincidentally while I've been
working on the LIKE implementation for string comparisons.

Why not implement like() and notlike() for macaddr data types which (if
both args are macaddr) will compare on manufacturer's fields alone? That
would seem to get all the functionality you might want.

Example:

SELECT * FROM machines where hwaddr LIKE
(select id from MacIdCodes where manuf = 'Intel');

or something like that.

That would avoid ginning up something artificial like a macaddr with
some fields zeroed out. We would still have an equality operator etc.

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...)?

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

Larry

Comments?

- 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

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

Thomas Lockhart <lockhart@alumni.caltech.edu> writes:

Why not implement like() and notlike() for macaddr data types which (if
both args are macaddr) will compare on manufacturer's fields alone? That
would seem to get all the functionality you might want.

That seems like an entirely unjustified overloading of the "LIKE"
operator. I don't see any reason why someone would expect a string-
pattern-match operator to have the semantics of "compare the
manufacturer part only" when applied to macaddr.

That would avoid ginning up something artificial like a macaddr with
some fields zeroed out.

If you don't like that, provide a function that extracts the
manufacturer part as a text string (and I guess another to extract the
low-order bits as text). Then a lookup to get the manufacturer name can
be done as a text-field search. There is plenty of precedent in the
inet/cidr functions for extracting portions of a data value as text
strings.

regards, tom lane

Why not implement like() and notlike() for macaddr data types which (if
both args are macaddr) will compare on manufacturer's fields alone? That
would seem to get all the functionality you might want.

That seems like an entirely unjustified overloading of the "LIKE"
operator. I don't see any reason why someone would expect a string-
pattern-match operator to have the semantics of "compare the
manufacturer part only" when applied to macaddr.

Well, because "similar" is a synonym for "like", at least in the Western
US. And because LIKE is a string-pattern-match operator only because
SQL9x has a limited view of the world, and doesn't have any types other
than strings for which "similar" could have an unambiguous meaning.

In this case it is pretty clear what "like" could mean since we are
comparing two MAC addresses.

That would avoid ginning up something artificial like a macaddr with
some fields zeroed out.

If you don't like that, provide a function that extracts the
manufacturer part as a text string (and I guess another to extract the
low-order bits as text). Then a lookup to get the manufacturer name can
be done as a text-field search. There is plenty of precedent in the
inet/cidr functions for extracting portions of a data value as text
strings.

Hmm. All I would really need is a "macaddr to text" conversion function
and Postgres will take care of the rest (so we could use the full string
pattern matching capabilities). So

SELECT m.* FROM machines m, mactbl WHERE mactbl.manuf = 'Intel'
AND m.mac LIKE (substring(mactbl.id for 8) || '%');

might get a list of all of your machines with intel cards in them. Or we
could store the manufacturer's fields as strings (e.g. '01:02:03'), in
which case the query becomes

SELECT m.* FROM machines m, mactbl WHERE mactbl.manuf = 'Intel'
AND m.mac LIKE (mactbl.id || '%');

Perhaps this is a better solution until someone complains about
performance (since we would be going through a bunch of printf's) but
I'll bet it isn't noticable in most instances. And I'd want the
macaddr->text and text->macaddr conversion functions anyway, so the code
will already be there to try.

Comments?

- Thomas

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@mythos.jpl.nasa.gov
[mailto:lockhart@mythos.jpl.nasa.gov]On Behalf Of Thomas Lockhart
Sent: Monday, August 07, 2000 10:41 AM
To: Larry Rosenman
Cc: pgsql-hackers@hub.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

Thomas Lockhart <lockhart@alumni.caltech.edu> writes:

Hmm. All I would really need is a "macaddr to text" conversion function
and Postgres will take care of the rest (so we could use the full string
pattern matching capabilities). So

SELECT m.* FROM machines m, mactbl WHERE mactbl.manuf = 'Intel'
AND m.mac LIKE (substring(mactbl.id for 8) || '%');

Ugh. That requires applications to make assumptions about what
text-string manipulation corresponds to "extract the manufacturer part".
What's so wrong with providing a function "manufacturer(macaddr)" to
encapsulate that knowledge?

Perhaps this is a better solution until someone complains about
performance (since we would be going through a bunch of printf's)

Lack of indexability of the WHERE clause is going to be a much bigger
performance problem than how many printf's are involved. If you're
trying to do a lookup in a table of manufacturer codes you want to be
able to compare equality to a search value, not have to do an unanchored
LIKE comparison at every tuple.

I do like providing a macaddr-to-text conversion function (if there's
not one already), since as you say it'd allow pattern-match searches
on more general patterns than "what's the manufacturer". But extracting
the manufacturer part is a common case that is part of the agreed-on
semantics of the type, so providing a function for it seems reasonable
to me.

regards, tom lane

At 11:57 AM 8/7/00 -0400, Tom Lane wrote:

Thomas Lockhart <lockhart@alumni.caltech.edu> writes:

Why not implement like() and notlike() for macaddr data types which (if
both args are macaddr) will compare on manufacturer's fields alone? That
would seem to get all the functionality you might want.

That seems like an entirely unjustified overloading of the "LIKE"
operator. I don't see any reason why someone would expect a string-
pattern-match operator to have the semantics of "compare the
manufacturer part only" when applied to macaddr.

It seems really unintuitive, breaking the "law of least astonishment",
since it isn't really at all like "LIKE". Which, after all, does an
exact match unless you wildcard.

I would think the trend would be to reduce items in the kludge bucket,
not add to them.

- Don Baccus, Portland OR <dhogaza@pacifier.com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.