Обсуждение: 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? 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
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
>
>
> 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, Pennsylvania19026
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
[ 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
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
[ 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
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
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
> 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 Serviceand other goodies at http://donb.photo.net.