Re: mac.c

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