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

RE: mac.c

From: "Larry Rosenman" <ler(at)lerctr(dot)org>
To: "Bruce Momjian" <pgman(at)candle(dot)pha(dot)pa(dot)us>, "Larry Rosenman" <ler(at)lerctr(dot)org>
Cc: "Thomas Lockhart" <lockhart(at)alumni(dot)caltech(dot)edu>, <pgsql-hackers(at)hub(dot)org>
Subject: RE: mac.c
Date: 2000-08-02 13:19:05
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
What about people that are using it?  Or will it get noted in the upgrade
path doc?


-----Original Message-----
From: pgsql-hackers-owner(at)hub(dot)org [mailto:pgsql-hackers-owner(at)hub(dot)org]On
Behalf Of Bruce Momjian
Sent: Wednesday, August 02, 2000 8:15 AM
To: Larry Rosenman
Cc: Thomas Lockhart; pgsql-hackers(at)hub(dot)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,
> 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

  Bruce Momjian                        |
  pgman(at)candle(dot)pha(dot)pa(dot)us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

In response to

  • Re: mac.c at 2000-08-02 13:14:32 from Bruce Momjian


  • Re: mac.c at 2000-08-02 13:34:22 from Bruce Momjian

pgsql-hackers by date

Next:From: jeff seamanDate: 2000-08-02 13:27:41
Subject: user authentication question
Previous:From: Bruce MomjianDate: 2000-08-02 13:14:32
Subject: Re: mac.c

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