Re: mac.c - Mailing list pgsql-hackers
From | Bruce Momjian |
---|---|
Subject | Re: mac.c |
Date | |
Msg-id | 200008021428.KAA03932@candle.pha.pa.us Whole thread Raw |
In response to | RE: mac.c ("Larry Rosenman" <ler@lerctr.org>) |
Responses |
RE: mac.c
|
List | pgsql-hackers |
[ 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
pgsql-hackers by date: