Re: mac.c

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: 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:34:22
Message-ID: 200008021334.JAA02406@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

[ 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(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,
> 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(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
>
>

--
Bruce Momjian | http://candle.pha.pa.us
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:19:05 from Larry Rosenman

Responses

  • RE: mac.c at 2000-08-02 13:39:16 from Larry Rosenman

Browse pgsql-hackers by date

  From Date Subject
Next Message Larry Rosenman 2000-08-02 13:39:16 RE: mac.c
Previous Message jeff seaman 2000-08-02 13:27:41 user authentication question