Re: Refactoring of command.c
От | John Gray |
---|---|
Тема | Re: Refactoring of command.c |
Дата | |
Msg-id | 1014767404.4447.9.camel@adzuki обсуждение исходный текст |
Ответ на | Re: Refactoring of command.c (Peter Eisentraut <peter_e@gmx.net>) |
Ответы |
Re: Refactoring of command.c
(Bruce Momjian <pgman@candle.pha.pa.us>)
Re: Refactoring of command.c (Peter Eisentraut <peter_e@gmx.net>) Re: Refactoring of command.c (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | 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 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
В списке pgsql-hackers по дате отправления:
Следующее
От: "Dann Corbit"Дата:
Сообщение: Re: eWeek Poll: Which database is most critical to your