Skip site navigation (1) Skip section navigation (2)

Re: mac.c

From: Alex Pilosov <alex(at)pilosoft(dot)com>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: Larry Rosenman <ler(at)lerctr(dot)org>, Thomas Lockhart <lockhart(at)alumni(dot)caltech(dot)edu>, pgsql-hackers(at)hub(dot)org
Subject: Re: mac.c
Date: 2000-07-27 04:11:21
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
It'd be nice (tm). I am using mac address types now, and certainly going
to be upset if they just disappear in next postgres version :P)

However, this is definitely a contrib feature, not a core postgres item.

Probably the macaddr type should be also moved to that contrib directory.

I suggest that the contrib would include a query that creates mac_manuf
table and a 'macaddr_manuf(macaddr) returns varchar' function which would
do a 'select name from mac_manuf m where m.mac=mac_trunc(macaddr)' and a
'mac_trunc(macaddr) returns macaddr' which would set the 3 lowest-order
nibbles to 0.

(I don't think macmanufacturer deserves a separate type).


On Wed, 26 Jul 2000, Bruce Momjian wrote:

> > All I want to do now (given the size stuff), is to have a function and
> > possibly a type to compare the 24-bit OUI's, and give the tools
> > in /contrib to load a table using these from the IEEE's list.
> > 
> > No more hardcoded stuff in the db. 
> > 
> > Does this make more sense?
> > 
> > It's definately extensible, and frees code space.
> I was just wondering if there was any real demand for this feature.

In response to

  • Re: mac.c at 2000-07-27 03:54:31 from Bruce Momjian


  • Re: mac.c at 2000-07-27 13:00:25 from Bruce Momjian

pgsql-hackers by date

Next:From: Tom LaneDate: 2000-07-27 04:26:07
Subject: Re: Warnings triggered by recent includefile cleanups
Previous:From: Alex PilosovDate: 2000-07-27 03:54:33
Subject: Re: Hello PL/Python

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group