Re: Refactoring of command.c

On Tue, 2002-02-26 at 19:19, Peter Eisentraut wrote:
> John Gray writes:
>
> > I imagined that the ALTER TABLE would move to alter.c (but maybe this
> > should be altertable.c?),
>
> Put all the table creation and altering code into the same file.
>

Following this, here is an overview of a possible rearrangement of the
files in the commands/ directory. Those not mentioned I intend to leave
alone. Obviously, I'd also change the include files (and any files
referencing them) to match.

The aim is that each filename will be either a) the name of a command
(explain, analyze, vacuum) or b) a type/class of database object.
(async.c would remain an exception to this)

The new table.c should be amenable to quite a bit of clearing up. I
expect that it might come out at around 9000 lines before that's done,
which is quite long, but it would at least be a well-defined subsystem.

command.c ALTER TABLE -> table.c
portal -> portal.c
LOCK -> lock.c

creatinh.c all code -> table.c

dbcommands.c rename to database.c (see below)

define.c see below

indexcmds.c rename to index.c (see below)

proclang.c case_translate_language_name currently also in define.c

remove.c see below

rename.c update_ri_trigger_args -> trigger.c
renameatt, renamerel -> table.c

define.c and remove.c

These files currently support the "smaller" entities. These could
obviously be split out, so that we have function.c, operator.c,
opclass.c, aggregate.c . This adds more files, but has the merit of
making it obvious where any further future support for these entities
should go. Any feelings about this?

renamed files

I know that "renamed" files in CVS will lose their history (for
tracability we presumably wouldn't rename them in the repository), so I
accept that it may not be a great idea to rename them, but it seems a
little redundant to use commands/dbcommands.c rather than
commands/database.c.

As I'm new to this kind of change, I assume that I'd just submit a
normal context diff for this and rely on it not getting tangled up with
any other patches to these files? Or is this *too* radical a reshuffle?
:-)

John