Skip site navigation (1) Skip section navigation (2)

Re: Refactoring of command.c

From: John Gray <jgray(at)azuli(dot)co(dot)uk>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Refactoring of command.c
Date: 2002-02-26 23:50:01
Message-ID: 1014767404.4447.9.camel@adzuki (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
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

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?


In response to


pgsql-hackers by date

Next:From: Dann CorbitDate: 2002-02-27 00:08:01
Subject: Re: eWeek Poll: Which database is most critical to your
Previous:From: Tom LaneDate: 2002-02-26 23:43:56
Subject: Re: single task postgresql

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group