Re: pgsql/src/backend/optimizer/prep/_deadcode pre ...

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-committers(at)postgresql(dot)org
Subject: Re: pgsql/src/backend/optimizer/prep/_deadcode pre ...
Date: 2002-07-30 19:13:04
Message-ID: 200207301913.g6UJD4510550@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers

Tom Lane wrote:
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> >> If we're cleaning out _deadcode, might as well zap this one too.
>
> > Uh, that was the one for KSQO. Did we want to keep that?
>
> I didn't.
>
> > I guess not
> > but will just have to remember it is in CVS. I was thinking we should
> > add a file at the top of /src listing the files we have removed but are
> > in CVS for later reuse. Comments?
>
> Seems like a waste of time --- the potentially useful stuff in back
> archived versions is not cleanly organized into files that we deleted
> (vs ones we still have). Will you want to start including a log of
> every code deletion?

I bring it up because code deletions show up in the 'cvs log' of the
still-existing file, while file deletions really are invisible unless
you know the file was there before. I assume this was Marc's reason for
objecting to the file removals in the first place. Not sure I agree,
but I see the point.

--
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

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Tom Lane 2002-07-30 19:23:50 Re: pgsql/src/backend/optimizer/prep/_deadcode pre ...
Previous Message Tom Lane 2002-07-30 19:11:26 Re: pgsql/src/backend/optimizer/prep/_deadcode pre ...