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

Tom Lane wrote:

CVSROOT: /cvsroot
Module name: pgsql
Changes by: tgl@postgresql.org 02/07/30 14:54:59

Removed files:
src/backend/optimizer/prep/_deadcode: prepkeyset.c

Log message:
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 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?

-- 
  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 <pgman@candle.pha.pa.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?

regards, tom lane

Tom Lane wrote:

Bruce Momjian <pgman@candle.pha.pa.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@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 <pgman@candle.pha.pa.us> writes:

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.

Which you can find out by looking in the "Attic" subdirectory. I don't
think file removals are any "more invisible" in CVS than code removals
within a file.

regards, tom lane

Tom Lane wrote:

Bruce Momjian <pgman@candle.pha.pa.us> writes:

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.

Which you can find out by looking in the "Attic" subdirectory. I don't
think file removals are any "more invisible" in CVS than code removals
within a file.

I don't see any Attic directory in my CVS. Do I have to look in the CVS
tree? If so, it is more invisible.

-- 
  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 <pgman@candle.pha.pa.us> writes:

I don't see any Attic directory in my CVS. Do I have to look in the CVS
tree? If so, it is more invisible.

A checked-out copy of CVS doesn't have any history in it anyway; you
always have to go to the server (or a local cvsup repository) to see
the history. So I don't really see the difference here.

Even more to the point, if we really thought those files would be of
future interest, they'd not have gotten removed in the first place.
We'd just have done #ifdef NOT_USED or some such. I don't see much
point in a manually maintained (and therefore surely incomplete and
inaccurate) index to uninteresting code...

regards, tom lane

Tom Lane wrote:

Bruce Momjian <pgman@candle.pha.pa.us> writes:

I don't see any Attic directory in my CVS. Do I have to look in the CVS
tree? If so, it is more invisible.

A checked-out copy of CVS doesn't have any history in it anyway; you
always have to go to the server (or a local cvsup repository) to see
the history. So I don't really see the difference here.

Yes, but from my command line, I can see the changes made to any file.
How do I see attic files from the command line?

-- 
  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 <pgman@candle.pha.pa.us> writes:

Yes, but from my command line, I can see the changes made to any file.
How do I see attic files from the command line?

cvs log doesn't seem to have any problem with that.

$ cd ~/pgsql/src/backend/commands
$ cvs log | grep Attic
cvs server: Logging .
RCS file: /cvsroot/pgsql/src/backend/commands/Attic/Makefile.inc,v
RCS file: /cvsroot/pgsql/src/backend/commands/Attic/async.h,v
... etc ...

$ cvs log async.h

RCS file: /cvsroot/pgsql/src/backend/commands/Attic/async.h,v
Working file: async.h
... etc ...
revision 1.2
date: 1996/08/28 07:16:07; author: scrappy; state: dead; lines: +1 -1
Clean up th ecompile process by centralizing the include files

- code compile tested, but due to a yet unresolved problem with
parse.h's creation, compile not completed...
----------------------------

$

regards, tom lane

I see, the log shows the file and the info about it. Makes sense. It
is just one more step to finding the file.

---------------------------------------------------------------------------

Tom Lane wrote:

Bruce Momjian <pgman@candle.pha.pa.us> writes:

Yes, but from my command line, I can see the changes made to any file.
How do I see attic files from the command line?

cvs log doesn't seem to have any problem with that.

$ cd ~/pgsql/src/backend/commands
$ cvs log | grep Attic
cvs server: Logging .
RCS file: /cvsroot/pgsql/src/backend/commands/Attic/Makefile.inc,v
RCS file: /cvsroot/pgsql/src/backend/commands/Attic/async.h,v
... etc ...

$ cvs log async.h

RCS file: /cvsroot/pgsql/src/backend/commands/Attic/async.h,v
Working file: async.h
... etc ...
revision 1.2
date: 1996/08/28 07:16:07; author: scrappy; state: dead; lines: +1 -1
Clean up th ecompile process by centralizing the include files

- code compile tested, but due to a yet unresolved problem with
parse.h's creation, compile not completed...
----------------------------

$

regards, tom lane

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