Thread: mac.c

mac.c

From
Larry Rosenman
Date:
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?

Any comments on the ouiparse.awk script?

LER

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


Re: mac.c

From
Alex Pilosov
Date:
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?
> 
> Any comments on the ouiparse.awk script?
> 
> LER
> 
> 




Re: mac.c

From
Thomas Lockhart
Date:
> 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


Re: mac.c

From
Larry Rosenman
Date:
> > 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


Re: mac.c

From
Bruce Momjian
Date:
> > > 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,
Pennsylvania19026
 


RE: mac.c

From
"Larry Rosenman"
Date:
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,
Pennsylvania19026
 



Re: mac.c

From
Bruce Momjian
Date:
[ 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,
Pennsylvania19026
 


RE: mac.c

From
"Larry Rosenman"
Date:
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,
Pennsylvania19026
 



Re: mac.c

From
Bruce Momjian
Date:
[ 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,
Pennsylvania19026
 


RE: mac.c

From
"Larry Rosenman"
Date:
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,
Pennsylvania19026
 



RE: mac.c

From
"Larry Rosenman"
Date:
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,
Pennsylvania19026
 



Re: mac.c

From
Thomas Lockhart
Date:
> 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


Re: mac.c

From
Larry Rosenman
Date:
> > 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


Re: mac.c

From
Thomas Lockhart
Date:
> 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


Re: mac.c

From
Tom Lane
Date:
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


Re: mac.c

From
Thomas Lockhart
Date:
> > 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


RE: mac.c

From
"Larry Rosenman"
Date:
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



Re: mac.c

From
Tom Lane
Date:
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


Re: mac.c

From
Don Baccus
Date:
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
Serviceand other goodies at http://donb.photo.net.