Re: select on macaddr field type yields incorrect response

pgsql-bugs(at)postgresql(dot)org writes:
> so, the 4th octet is being corrupted somehow.

> I have tried various query strings to see if uppercase or lowercase,
> or dashes vs. colons between the octets might be causing the problem,
> but I get the same results every time. The server side is 6.5.3.

There's a silly little typo in 6.5 that might cause this problem:

===================================================================
RCS file: /home/projects/pgsql/cvsroot/pgsql/src/backend/utils/adt/mac.c,v
retrieving revision 1.13
retrieving revision 1.14
diff -u -r1.13 -r1.14
--- pgsql/src/backend/utils/adt/mac.c 1999/07/17 20:17:57 1.13
+++ pgsql/src/backend/utils/adt/mac.c 1999/12/16 01:30:49 1.14
@@ -1,7 +1,7 @@
/*
* PostgreSQL type definitions for MAC addresses.
*
- * $Id: mac.c,v 1.13 1999/07/17 20:17:57 momjian Exp $
+ * $Id: mac.c,v 1.14 1999/12/16 01:30:49 momjian Exp $
*/


@@ -132,7 +132,7 @@
((unsigned long)((addr->a<<16)|(addr->b<<8)|(addr->c)))

#define lobits(addr) \
- ((unsigned long)((addr->c<<16)|(addr->e<<8)|(addr->f)))
+ ((unsigned long)((addr->d<<16)|(addr->e<<8)|(addr->f)))

/*
* MAC address reader. Accepts several common notations.

If you don't want to update to 7.0 right now, you could just apply
this source patch instead. Note you will need to drop and recreate
any indexes on MAC columns after fixing this --- the real cause of
your observed result is incorrect ordering of the index due to
buggy behavior of the datatype's comparison routines.

regards, tom lane